Mutations for McpServer

[geelen]

McpServer is a great higher-level builder pattern for defining servers, but following on from #233 I feel it's a bit too limited to be used as a base for building other abstractions upon.

This PR adds:

• updateTool() and removeTool()
• updateResource() and removeResource()
• updatePrompt() and removePrompt()
• Update methods have the same signature as the existing methods for creating, but throw if the resource/prompt/tool their referencing doesn't exist
• All these methods emit list changed notifications automatically, as long as the server is currently connected to a transport

Motivation and Context

This feels like a flexible but low-enough level addition to make it easier to start to build "dynamic" servers on top of the current class, without imposing any particular design decision.

How Has This Been Tested?

Added tests to mcp.test.ts

Breaking Changes

Purely additive. The only change is that servers now, by default, report that they support listChanged notifications (since they do, now).

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[jmorrell-cloudflare]

Do we need to manage adding / removing tools to the server itself, or just shape which ones are returned on a request? Ex: a server could register a different handler here: https://github.com/modelcontextprotocol/typescript-sdk/blob/main/src/server/mcp.ts#L105

this.server.setRequestHandler(ListToolsRequestSchema, async ():  Promise<ListToolsResult> => {
  let userState = await fetchUserStateFromDataStore();
  let tools: Tool[] = this._registeredTools.filter((tool) => {
    // arbitrary filter by userState
  });

  return {
    tools: tools.map(
      ([name, tool]): Tool => {
        return {
          name,
          description: tool.description,
          inputSchema: tool.inputSchema
            ? (zodToJsonSchema(tool.inputSchema, {
                strictUnions: true,
              }) as Tool["inputSchema"])
            : EMPTY_OBJECT_JSON_SCHEMA,
        };
      },
    ),
  };
});

Note that the current version does not support async calls

Edit: I think this ~aligns with your approach in #233 ?

[geelen]

Do we need to manage adding / removing tools to the server itself, or just shape which ones are returned on a request?

The only issue is making sure you're triggering the listChanged notifications automatically so clients even know to ask for the updated list.

But yes, this PR is mainly about keeping the existing style of the McpServer class (i.e. methods that mutate internal state) and extending it to allow some dynamism, e.g.

const server = new McpServer({
  name: "Dynamic Example",
  version: "1.0.0"
});

server.tool(
  "listMessages",
  { channel: z.string() },
  async ({ channel }) => ({
    content: [{ type: "text", text: await listMessages(channel) }]
  })
);

server.tool(
  "upgradeAuth",
  { permission: z.enum(["write', vadmin"])},
  upgradeAuth
)

// Connect with the existing set of tools
const transport = new StdioServerTransport();
await server.connect(transport);

// Any mutations after connection result in `listChanged` notifications so the client knows to refresh
async function upgradeAuth({permission}) {
  const { ok, err, previous } = await upgradeAuthAndStoreToken(permission)

  if (!ok) return {content: [{ type: "text", text: `Error: ${err}` }]}

  // If we previously had read-only access, we need to add 'putMessage' now we can use it
  if (previous === "read") {
    server.tool(
      "putMessage",
      { channel: z.string(), message: z.string() },
      async ({ channel, message }) => ({
        content: [{ type: "text", text: await putMessage(channel, string) }]
      })
    );
  }

  // If we've just upgraded to 'write' permissions, we can still call 'upgradeAuth' but can only upgrade to 'admin' 
  if (permission === 'write') {
    server.updateTool(
      "upgradeAuth",
      { permission: z.enum(["admin"])}, // change param validation
      upgradeAuth
    )
  } else {
    // If we're on admin, we no longer have anywhere to upgrade to
    server.removeTool("upgradeAuth")
  }
}

(I've added the above example to the README as part of this PR)

But you're right, like in #233, we could build a much more reactive approach with tools being toggled on/off against the base class, which I think will be more maintainable in the long run.

But I like using McpServer! And don't want it to be forever locked into only offering static servers! Or, to put it another way, I want people to see that dynamic McpServers are possible, as a gateway to understanding why a ReactiveMcpServer is a good idea.