[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@modelcontextprotocol/client@2.5.0

Minor Changes

• #3115 1e608ca Thanks @mattzcarey! - Client, Server and McpServer now emit OpenTelemetry spans and mcp.client.operation.duration / mcp.server.operation.duration histograms for every MCP request and notification except notifications/message, following the OpenTelemetry semantic conventions for MCP, and propagate W3C trace context through params._meta (SEP-414). There is nothing to configure: register an OpenTelemetry SDK and MCP traffic shows up. Pass openTelemetry: false to a Client, Server or McpServer to turn its instrumentation off. Without one, the OpenTelemetry API is a no-op, nothing is recorded and messages are unchanged.

  @opentelemetry/api (^1.9.0) is a new required peer dependency of @modelcontextprotocol/client and @modelcontextprotocol/server, so the SDK uses the same copy as the application's OpenTelemetry SDK. npm 7+, pnpm 8+ and Bun install it automatically. Setups that don't install peers must add @opentelemetry/api to their dependencies, or importing either package fails: Yarn (classic, and Berry with any linker), npm --legacy-peer-deps, and pnpm with auto-install-peers=false.

  What changes for applications that already run an OpenTelemetry SDK:

  • MCP spans and metrics appear under the @modelcontextprotocol/client and @modelcontextprotocol/server instrumentation scopes. If you already trace MCP, pass openTelemetry: false, or with Sentry remove its McpServer integration, to avoid duplicate spans. Filtering the MCP scopes instead leaves handler spans parented on spans that are never exported.
  • Outgoing requests and notifications carry whatever your global propagator writes, in params._meta, as HTTP requests carry it in headers: traceparent and tracestate, plus baggage if the propagator includes W3C Baggage (the NodeSDK default), so baggage entries reach MCP peers, including third-party servers. Register W3CTraceContextPropagator alone to send trace context only.
  • Servers that validate a custom method's params with a strict schema need an optional _meta member, as they already do for callers that pass onprogress.

  Spans do not record tool arguments, tool results or prompt arguments. They do record JSON-RPC error messages, handler exception messages and resource URIs. The span and attribute names are experimental while the MCP semantic conventions are in development.

Patch Changes

• #3108 39ae8e6 Thanks @claude! - The bundled Ajv validator is now built with fast-uri 3.1.9 (was 3.1.8). A schema no longer compiles when a $id or $ref has a percent-encoded character before its first colon (%61:b), or { or } in the host of an http, https, ws or wss URL (http://{host}/a). Relative values keep their leading .. segments: a $ref to a $id such as ../a now resolves, and a $ref of only dot segments (., ../) no longer resolves to the root schema. Plain names, #/$defs/... references, other URLs and URNs are not affected.

• #2877 b415e60 Thanks @dasjideepak! - Add OAuthClientProvider.skipOfflineAccessConsentPrompt (and the matching startAuthorization() option) so a client can omit the prompt=consent the SDK adds when the requested scope includes offline_access. Default behavior is unchanged. This unblocks authorization servers such as Microsoft Entra ID tenants that have user consent disabled and admin consent granted, where a forced consent prompt fails with AADSTS90095 for non-admin users.

• Updated dependencies []:

  • @modelcontextprotocol/core@2.5.0

@modelcontextprotocol/server@2.5.0

Minor Changes

• #3115 1e608ca Thanks @mattzcarey! - Client, Server and McpServer now emit OpenTelemetry spans and mcp.client.operation.duration / mcp.server.operation.duration histograms for every MCP request and notification except notifications/message, following the OpenTelemetry semantic conventions for MCP, and propagate W3C trace context through params._meta (SEP-414). There is nothing to configure: register an OpenTelemetry SDK and MCP traffic shows up. Pass openTelemetry: false to a Client, Server or McpServer to turn its instrumentation off. Without one, the OpenTelemetry API is a no-op, nothing is recorded and messages are unchanged.

  @opentelemetry/api (^1.9.0) is a new required peer dependency of @modelcontextprotocol/client and @modelcontextprotocol/server, so the SDK uses the same copy as the application's OpenTelemetry SDK. npm 7+, pnpm 8+ and Bun install it automatically. Setups that don't install peers must add @opentelemetry/api to their dependencies, or importing either package fails: Yarn (classic, and Berry with any linker), npm --legacy-peer-deps, and pnpm with auto-install-peers=false.

  What changes for applications that already run an OpenTelemetry SDK:

  • MCP spans and metrics appear under the @modelcontextprotocol/client and @modelcontextprotocol/server instrumentation scopes. If you already trace MCP, pass openTelemetry: false, or with Sentry remove its McpServer integration, to avoid duplicate spans. Filtering the MCP scopes instead leaves handler spans parented on spans that are never exported.
  • Outgoing requests and notifications carry whatever your global propagator writes, in params._meta, as HTTP requests carry it in headers: traceparent and tracestate, plus baggage if the propagator includes W3C Baggage (the NodeSDK default), so baggage entries reach MCP peers, including third-party servers. Register W3CTraceContextPropagator alone to send trace context only.
  • Servers that validate a custom method's params with a strict schema need an optional _meta member, as they already do for callers that pass onprogress.

  Spans do not record tool arguments, tool results or prompt arguments. They do record JSON-RPC error messages, handler exception messages and resource URIs. The span and attribute names are experimental while the MCP semantic conventions are in development.

Patch Changes

• #3108 39ae8e6 Thanks @claude! - The bundled Ajv validator is now built with fast-uri 3.1.9 (was 3.1.8). A schema no longer compiles when a $id or $ref has a percent-encoded character before its first colon (%61:b), or { or } in the host of an http, https, ws or wss URL (http://{host}/a). Relative values keep their leading .. segments: a $ref to a $id such as ../a now resolves, and a $ref of only dot segments (., ../) no longer resolves to the root schema. Plain names, #/$defs/... references, other URLs and URNs are not affected.

• #3167 919bb8e Thanks @mattzcarey! - Reject a tools/call with 400 / -32020 (HeaderMismatch) when a body argument declared with x-mcp-header is an object or array, with or without its Mcp-Param-* header, and when the argument is an integer outside the safe range but the header is present. Previously the header check was skipped for these values, so the call reached the tool.

• Updated dependencies []:

  • @modelcontextprotocol/core@2.5.0

@modelcontextprotocol/server-legacy@2.5.0

Patch Changes

• Updated dependencies []:
  • @modelcontextprotocol/core@2.5.0

@modelcontextprotocol/codemod@2.5.0

@modelcontextprotocol/core@2.5.0

@modelcontextprotocol/core-internal@2.1.0

Minor Changes

• #3115 1e608ca Thanks @mattzcarey! - Client, Server and McpServer now emit OpenTelemetry spans and mcp.client.operation.duration / mcp.server.operation.duration histograms for every MCP request and notification except notifications/message, following the OpenTelemetry semantic conventions for MCP, and propagate W3C trace context through params._meta (SEP-414). There is nothing to configure: register an OpenTelemetry SDK and MCP traffic shows up. Pass openTelemetry: false to a Client, Server or McpServer to turn its instrumentation off. Without one, the OpenTelemetry API is a no-op, nothing is recorded and messages are unchanged.

  @opentelemetry/api (^1.9.0) is a new required peer dependency of @modelcontextprotocol/client and @modelcontextprotocol/server, so the SDK uses the same copy as the application's OpenTelemetry SDK. npm 7+, pnpm 8+ and Bun install it automatically. Setups that don't install peers must add @opentelemetry/api to their dependencies, or importing either package fails: Yarn (classic, and Berry with any linker), npm --legacy-peer-deps, and pnpm with auto-install-peers=false.

  What changes for applications that already run an OpenTelemetry SDK:

  • MCP spans and metrics appear under the @modelcontextprotocol/client and @modelcontextprotocol/server instrumentation scopes. If you already trace MCP, pass openTelemetry: false, or with Sentry remove its McpServer integration, to avoid duplicate spans. Filtering the MCP scopes instead leaves handler spans parented on spans that are never exported.
  • Outgoing requests and notifications carry whatever your global propagator writes, in params._meta, as HTTP requests carry it in headers: traceparent and tracestate, plus baggage if the propagator includes W3C Baggage (the NodeSDK default), so baggage entries reach MCP peers, including third-party servers. Register W3CTraceContextPropagator alone to send trace context only.
  • Servers that validate a custom method's params with a strict schema need an optional _meta member, as they already do for callers that pass onprogress.

  Spans do not record tool arguments, tool results or prompt arguments. They do record JSON-RPC error messages, handler exception messages and resource URIs. The span and attribute names are experimental while the MCP semantic conventions are in development.

Patch Changes

• #3167 919bb8e Thanks @mattzcarey! - Reject a tools/call with 400 / -32020 (HeaderMismatch) when a body argument declared with x-mcp-header is an object or array, with or without its Mcp-Param-* header, and when the argument is an integer outside the safe range but the header is present. Previously the header check was skipped for these values, so the call reached the tool.

• Updated dependencies []:

  • @modelcontextprotocol/core@2.5.0