v0.8.0

Breaking

• A STATIC client of createMcpServer whose startup toolsets fail to register their tools now gets a JSON-RPC error (-32603, HTTP 500, "Failed to load toolsets for this client.") on initialize instead of connecting with only some of its tools. The failed bundle is dropped, so the client's next initialize retries the load. (#33)
  • ServerOrchestrator.isReady() now returns false, and ensureReady() throws, when registering a startup toolset's tools fails (for example a duplicate tool name, within a toolset or across toolsets when namespaceToolsWithSetKey is off). It used to report ready. createMcpServer therefore rejects at startup for such a catalog in STATIC mode, where it used to start with the partial toolset. enableToolset results (and the enable_toolset meta-tool output) gain an optional code on that failure.
  • createPermissionBasedMcpServer is not affected: it enables each client's permitted toolsets itself, still connects a client when only some of them fail (failedToolsets), and still answers 403 when all of them fail.
  • Toolsets refused before registration (exposure policy, duplicate names in startup.toolsets) and module loader errors do not count as failures.
  • Migration: before upgrading, make sure no two startup toolsets register the same tool name (rename or remove the duplicate, or turn on namespaceToolsWithSetKey). A catalog that only worked because the collision was swallowed will now fail initialize, or fail at startup in STATIC mode.

Added

• http.allowedOrigins validates the Origin header on the /mcp endpoints, as the MCP spec requires. A request with an Origin outside the list gets 403; requests without an Origin header are always allowed. When cors is on, only the listed origins get CORS access. Not set by default, so existing deployments behave as before. (#32)
  • Migration: none needed. To turn it on, pass http: { allowedOrigins: ["https://app.example.com"] }.

Changed

• disable_toolset now removes the toolset's tools from the MCP server, so clients no longer list or call them, and the toolset can be enabled again. Before, it only changed the toolset's state and the tools stayed callable. The disable message ends with Removed N tools.; a partly failed enable also rolls back the tools it had registered. Clients get one tools/list_changed per removed tool plus the batched one. (#31)
  • Migration: code that relied on a disabled toolset's tools staying callable must stop doing so.
• enable_toolset and disable_toolset are advertised with destructiveHint: false, idempotentHint: true. They only change which tools are exposed, so clients no longer need to treat them as destructive. (#29)

Fixed

• PermissionAwareFastifyTransport waits for the client's orchestrator to be ready before connecting and, like FastifyTransport, answers 500 / -32603 and drops the bundle when it is not ready. Internal hardening: the class is not part of the public API and createPermissionBasedMcpServer already loaded toolsets before returning, so its behaviour is unchanged. (#30)

What's Changed

• feat(http): validate Origin on /mcp via http.allowedOrigins by @imbenrabi in #32
• fix: wait for the orchestrator before connecting a permission-aware client by @imbenrabi in #30
• fix: mark enable_toolset and disable_toolset as non-destructive by @imbenrabi in #29
• fix: reject STATIC clients whose startup toolsets failed to load by @imbenrabi in #33
• fix: disable_toolset unregisters the toolset's tools by @imbenrabi in #31
• chore(release): 0.8.0 by @imbenrabi in #34

Full Changelog: v0.7.0...v0.8.0