Version Packages (beta)

[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.

⚠️⚠️⚠️⚠️⚠️⚠️

main is currently in pre mode so this branch has prereleases rather than normal releases. If you want to exit prereleases, run changeset pre exit on main.

⚠️⚠️⚠️⚠️⚠️⚠️

Releases

@modelcontextprotocol/client@2.0.0-beta.5

Minor Changes

• #2501 1480241 Thanks @felixweinberger! - Export the Protocol base class and mergeCapabilities from the @modelcontextprotocol/client and @modelcontextprotocol/server package roots, restoring the v1 import for consumers that subclass Protocol (e.g. the MCP Apps SDK). The client and server packages each bundle their own compiled copy of the class, so import it from one package consistently within a process.

  The codemod now rewrites Protocol and mergeCapabilities imports from shared/protocol.js to the client or server package root, like the module's other symbols, instead of dropping them with an action-required marker.

• #2511 f60dff0 Thanks @felixweinberger! - ConnectOptions.prior accepts a cached era verdict — the new exported type PriorDiscovery. { kind: 'modern', discover } adopts a previously obtained DiscoverResult with zero round trips; { kind: 'legacy' } skips the server/discover probe and runs the plain initialize handshake directly, for servers known out-of-band to be legacy — without pinning the client to mode: 'legacy': stop supplying the verdict and connect() falls back to the configured versionNegotiation mode (under 'auto', it re-probes and rediscovers an upgraded server). Freshness is the supplying host's responsibility — a stale legacy verdict succeeds silently against an upgraded server, so hosts must date cached legacy verdicts in their own storage and stop supplying them past their policy horizon. Persisted-blob plumbing is hardened: prior: null is treated as absent, the modern arm's discover payload is schema-validated before any connection state changes, and an unrecognized shape rejects with a typed SdkError(EraNegotiationFailed) instead of a TypeError.

• #2513 f413763 Thanks @felixweinberger! - Align the 2026-07-28 wire with the final revision (spec PR #3002): serverInfo moves from the DiscoverResult body to the result _meta, and the per-request envelope's clientInfo demotes from required to SHOULD.

  Before this change the SDK shipped the pre-#3002 shape in both directions: the client hard-rejected a conforming server's DiscoverResult (missing body serverInfo failed parse, so the probe misclassified the server as legacy and attempted an initialize handshake against it — a hard connect failure against a modern-only server such as go-sdk v1.7.0-pre.3), and the server rejected conforming clients that omit clientInfo.

  Now:

  • The 2026 wire schemas are the final revision exactly: no body serverInfo on DiscoverResult, envelope clientInfo optional (a present-but-malformed value still fails validation).
  • Servers stamp _meta['io.modelcontextprotocol/serverInfo'] on every 2026-era response (spec SHOULD; a handler-authored value wins, the 2025-era wire is untouched). This includes the entry-built subscriptions/listen graceful-close results — the spec's SubscriptionsListenResultMeta extends ResultMetaObject.
  • Clients keep sending clientInfo and read server identity from the discover result's _meta only. A server that stamps no identity is anonymous: getServerVersion() is undefined and the response cache partitions under a per-connection surrogate. A malformed _meta serverInfo value is treated as absent on receive (the spec marks the field self-reported, unverified, and display-only).
  • Breaking type changes: DiscoverResult no longer declares serverInfo; RequestMetaEnvelope's clientInfo is optional. New public constant SERVER_INFO_META_KEY ('io.modelcontextprotocol/serverInfo').

Patch Changes

• Updated dependencies [f413763]:
  • @modelcontextprotocol/core@2.0.0-beta.5

@modelcontextprotocol/core@2.0.0-beta.5

Minor Changes

• #2513 f413763 Thanks @felixweinberger! - Align the 2026-07-28 wire with the final revision (spec PR #3002): serverInfo moves from the DiscoverResult body to the result _meta, and the per-request envelope's clientInfo demotes from required to SHOULD.

  Before this change the SDK shipped the pre-#3002 shape in both directions: the client hard-rejected a conforming server's DiscoverResult (missing body serverInfo failed parse, so the probe misclassified the server as legacy and attempted an initialize handshake against it — a hard connect failure against a modern-only server such as go-sdk v1.7.0-pre.3), and the server rejected conforming clients that omit clientInfo.

  Now:

  • The 2026 wire schemas are the final revision exactly: no body serverInfo on DiscoverResult, envelope clientInfo optional (a present-but-malformed value still fails validation).
  • Servers stamp _meta['io.modelcontextprotocol/serverInfo'] on every 2026-era response (spec SHOULD; a handler-authored value wins, the 2025-era wire is untouched). This includes the entry-built subscriptions/listen graceful-close results — the spec's SubscriptionsListenResultMeta extends ResultMetaObject.
  • Clients keep sending clientInfo and read server identity from the discover result's _meta only. A server that stamps no identity is anonymous: getServerVersion() is undefined and the response cache partitions under a per-connection surrogate. A malformed _meta serverInfo value is treated as absent on receive (the spec marks the field self-reported, unverified, and display-only).
  • Breaking type changes: DiscoverResult no longer declares serverInfo; RequestMetaEnvelope's clientInfo is optional. New public constant SERVER_INFO_META_KEY ('io.modelcontextprotocol/serverInfo').

@modelcontextprotocol/server@2.0.0-beta.5

Minor Changes

• #2501 1480241 Thanks @felixweinberger! - Export the Protocol base class and mergeCapabilities from the @modelcontextprotocol/client and @modelcontextprotocol/server package roots, restoring the v1 import for consumers that subclass Protocol (e.g. the MCP Apps SDK). The client and server packages each bundle their own compiled copy of the class, so import it from one package consistently within a process.

  The codemod now rewrites Protocol and mergeCapabilities imports from shared/protocol.js to the client or server package root, like the module's other symbols, instead of dropping them with an action-required marker.

• #2513 f413763 Thanks @felixweinberger! - Align the 2026-07-28 wire with the final revision (spec PR #3002): serverInfo moves from the DiscoverResult body to the result _meta, and the per-request envelope's clientInfo demotes from required to SHOULD.

  Before this change the SDK shipped the pre-#3002 shape in both directions: the client hard-rejected a conforming server's DiscoverResult (missing body serverInfo failed parse, so the probe misclassified the server as legacy and attempted an initialize handshake against it — a hard connect failure against a modern-only server such as go-sdk v1.7.0-pre.3), and the server rejected conforming clients that omit clientInfo.

  Now:

  • The 2026 wire schemas are the final revision exactly: no body serverInfo on DiscoverResult, envelope clientInfo optional (a present-but-malformed value still fails validation).
  • Servers stamp _meta['io.modelcontextprotocol/serverInfo'] on every 2026-era response (spec SHOULD; a handler-authored value wins, the 2025-era wire is untouched). This includes the entry-built subscriptions/listen graceful-close results — the spec's SubscriptionsListenResultMeta extends ResultMetaObject.
  • Clients keep sending clientInfo and read server identity from the discover result's _meta only. A server that stamps no identity is anonymous: getServerVersion() is undefined and the response cache partitions under a per-connection surrogate. A malformed _meta serverInfo value is treated as absent on receive (the spec marks the field self-reported, unverified, and display-only).
  • Breaking type changes: DiscoverResult no longer declares serverInfo; RequestMetaEnvelope's clientInfo is optional. New public constant SERVER_INFO_META_KEY ('io.modelcontextprotocol/serverInfo').

Patch Changes

• Updated dependencies [f413763]:
  • @modelcontextprotocol/core@2.0.0-beta.5

@modelcontextprotocol/codemod@2.0.0-beta.5

Patch Changes

• #2501 1480241 Thanks @felixweinberger! - Export the Protocol base class and mergeCapabilities from the @modelcontextprotocol/client and @modelcontextprotocol/server package roots, restoring the v1 import for consumers that subclass Protocol (e.g. the MCP Apps SDK). The client and server packages each bundle their own compiled copy of the class, so import it from one package consistently within a process.

  The codemod now rewrites Protocol and mergeCapabilities imports from shared/protocol.js to the client or server package root, like the module's other symbols, instead of dropping them with an action-required marker.

@modelcontextprotocol/express@2.0.0-beta.5

Patch Changes

• Updated dependencies [1480241, f413763]:
  • @modelcontextprotocol/server@2.0.0-beta.5

@modelcontextprotocol/fastify@2.0.0-beta.5

Patch Changes

• Updated dependencies [1480241, f413763]:
  • @modelcontextprotocol/server@2.0.0-beta.5

@modelcontextprotocol/hono@2.0.0-beta.5

Patch Changes

• Updated dependencies [1480241, f413763]:
  • @modelcontextprotocol/server@2.0.0-beta.5

@modelcontextprotocol/node@2.0.0-beta.5

Patch Changes

• Updated dependencies [1480241, f413763]:
  • @modelcontextprotocol/server@2.0.0-beta.5

@modelcontextprotocol/server-legacy@2.0.0-beta.5

Patch Changes

• Updated dependencies [f413763]:
  • @modelcontextprotocol/core@2.0.0-beta.5

@modelcontextprotocol/core-internal@2.0.0-beta.4

Minor Changes

• #2501 1480241 Thanks @felixweinberger! - Export the Protocol base class and mergeCapabilities from the @modelcontextprotocol/client and @modelcontextprotocol/server package roots, restoring the v1 import for consumers that subclass Protocol (e.g. the MCP Apps SDK). The client and server packages each bundle their own compiled copy of the class, so import it from one package consistently within a process.

  The codemod now rewrites Protocol and mergeCapabilities imports from shared/protocol.js to the client or server package root, like the module's other symbols, instead of dropping them with an action-required marker.

• #2513 f413763 Thanks @felixweinberger! - Align the 2026-07-28 wire with the final revision (spec PR #3002): serverInfo moves from the DiscoverResult body to the result _meta, and the per-request envelope's clientInfo demotes from required to SHOULD.

  Before this change the SDK shipped the pre-#3002 shape in both directions: the client hard-rejected a conforming server's DiscoverResult (missing body serverInfo failed parse, so the probe misclassified the server as legacy and attempted an initialize handshake against it — a hard connect failure against a modern-only server such as go-sdk v1.7.0-pre.3), and the server rejected conforming clients that omit clientInfo.

  Now:

  • The 2026 wire schemas are the final revision exactly: no body serverInfo on DiscoverResult, envelope clientInfo optional (a present-but-malformed value still fails validation).
  • Servers stamp _meta['io.modelcontextprotocol/serverInfo'] on every 2026-era response (spec SHOULD; a handler-authored value wins, the 2025-era wire is untouched). This includes the entry-built subscriptions/listen graceful-close results — the spec's SubscriptionsListenResultMeta extends ResultMetaObject.
  • Clients keep sending clientInfo and read server identity from the discover result's _meta only. A server that stamps no identity is anonymous: getServerVersion() is undefined and the response cache partitions under a per-connection surrogate. A malformed _meta serverInfo value is treated as absent on receive (the spec marks the field self-reported, unverified, and display-only).
  • Breaking type changes: DiscoverResult no longer declares serverInfo; RequestMetaEnvelope's clientInfo is optional. New public constant SERVER_INFO_META_KEY ('io.modelcontextprotocol/serverInfo').

Patch Changes

• Updated dependencies [f413763]:
  • @modelcontextprotocol/core@2.0.0-beta.5

[claude]

LGTM — mechanical changesets release PR (beta.5), generated by the release action with no hand edits.

What was reviewed:

• Version bumps match the sole new changeset (export-protocol-class, from merged #2501): minor for client/server/core-internal, patch for codemod, exactly as its frontmatter declares.
• Fixed-group behavior checked: core/client/server/server-legacy/codemod move to 2.0.0-beta.5 together; core's empty changelog entry and server-legacy's deps-only entry are standard for group members with no direct change.
• .changeset/pre.json adds only export-protocol-class to the consumed list; the changeset file remains on disk, which is correct in pre mode.
• Middleware packages (express/fastify/hono/node) bump as patch dependents of server, as expected.

Extended reasoning...

Overview

PR #2512 is the auto-generated "Version Packages (beta)" PR from the changesets release GitHub action. It touches 21 files: .changeset/pre.json plus package.json version fields and CHANGELOG.md entries for 10 packages. There are zero source-code changes — every hunk is mechanical changesets output.

Verification performed

The only new changeset consumed since beta.4 is export-protocol-class (PR #2501, merged as commit 1480241, the direct parent of this PR's commit). I read the changeset's frontmatter and confirmed the released bump levels match exactly: minor for @modelcontextprotocol/client, @modelcontextprotocol/server, and @modelcontextprotocol/core-internal; patch for @modelcontextprotocol/codemod. The .changeset/config.json fixed group (core, client, server, server-legacy, codemod) explains why all five move to 2.0.0-beta.5 together — including core's empty changelog section and server-legacy's deps-only entry, which are normal for fixed-group members with no direct change. core-internal (private, outside the fixed group) independently bumps beta.3 → beta.4. The four middleware packages bump as patch dependents of server. Per the repo's review conventions I also read the changelog prose against the implementation it describes — it is a verbatim copy of the #2501 changeset text, and that PR's export/codemod changes are already merged, so the prose promises nothing the code doesn't ship. In pre mode the changeset files correctly remain on disk while pre.json records consumption; the diff adds exactly one entry there.

Security risks

None. No executable code, dependencies, or CI configuration change — only version strings and changelog markdown. Publishing is a separate step taken by a maintainer merging this PR.

Level of scrutiny

Low. This is the canonical example of a machine-generated, mechanical PR: the changesets action produced it deterministically from already-reviewed, already-merged changesets. The human review effort belongs on the underlying PRs (here, #2501, which went through its own review), not on the version-bump artifact. The main judgment call — whether now is the right time to cut beta.5 — rests with whoever merges, and approval does not force that timing.

Other factors

The bug hunting system found no issues. The PR timeline has no reviewer comments or unresolved threads, and I have no prior reviews on this PR. Sibling "Version Packages (beta)" PRs (#2484 and earlier) follow the identical pattern and merged cleanly.

[claude]

LGTM — mechanical changesets "Version Packages (beta)" release PR generated by the changesets action.

What was reviewed

• Version bumps match the fixed group (core/client/server/server-legacy/codemod all → 2.0.0-beta.5) and core-internal (private, → 2.0.0-beta.4); middleware packages bump as dependents of server.
• .changeset/pre.json gains exactly the two new changeset entries (export-protocol-class from #2501, prior-legacy-verdict from #2511), both files present and their frontmatter matches the generated changelog placement.
• Changelog text is a verbatim copy of the changeset files; the empty core@2.0.0-beta.5 section is the expected fixed-group ride-along.

Extended reasoning...

Overview

PR #2512 is the automated "Version Packages (beta)" PR opened by the changesets/action bot. It touches 21 files: .changeset/pre.json plus package.json version fields and CHANGELOG.md prepends across the client, server, core, core-internal, codemod, server-legacy, and four middleware packages. No source code, build config, or CI changes are included.

Security risks

None. The diff contains only version-string bumps, changelog prose, and pre-mode bookkeeping in pre.json. No dependencies are added or changed (only workspace:-resolved internal versions move), and no executable code is modified.

Level of scrutiny

Low — this is the canonical mechanical release PR shape this repo merges on every release cycle (e.g. #2484 in recent history). The correct check is internal consistency of the generated output, which I verified: the .changeset/config.json fixed group ([core, client, server, server-legacy, codemod]) moves together to 2.0.0-beta.5; the private core-internal bumps independently beta.3 → beta.4; the four middleware packages bump as dependents of server; pre.json adds exactly the two changesets landed since the last release (export-protocol-class / #2501 and prior-legacy-verdict / #2511), both of which correspond to commits in main's history (1480241, f60dff0). Changelog entries are verbatim copies of the changeset files, with #2511 correctly appearing only in the client package.

Other factors

The bug hunting system found no bugs. The PR timeline has no human review comments or unresolved discussion. The substantive changes being released (#2501, #2511) were reviewed in their own PRs — this PR only records them. Per the repo's review conventions, changeset prose was checked against what the referenced commits claim to ship, and nothing in this diff contradicts them.

[claude]

LGTM — machine-generated changesets Version Packages PR; safe to merge whenever the release is intended.

What was reviewed

• Version bumps are consistent: all published packages move beta.4 → beta.5, private core-internal beta.3 → beta.4, and every changed package.json version matches its new CHANGELOG heading.
• CHANGELOG entries are verbatim transcriptions of the three changeset files (export-protocol-class, prior-legacy-verdict, spec-3002-servinfo-meta), with semver levels matching each changeset's frontmatter (e.g. codemod correctly gets a patch from #2501).
• .changeset/pre.json appends exactly those three names, alphabetically ordered, matching pre-mode behavior (changeset files are retained, not deleted); the source PRs #2501/#2511/#2513 are merged on main.
• No source code, workflow, or dependency-range changes — only versions, changelogs, and pre.json.

Extended reasoning...

Overview

PR #2512 is the standing "Version Packages (beta)" PR generated by the changesets/action bot. It touches 21 files: package.json version fields, CHANGELOG.md prepends, and .changeset/pre.json across the core, client, server, codemod, middleware, and server-legacy packages. It contains no source code changes.

Security risks

None. The diff modifies only version strings, changelog prose, and the pre-mode changeset ledger. No code paths, auth logic, dependency ranges, or CI workflows are altered. The only security-relevant consequence of merging is publishing a new beta to npm, which is the PR's explicit and expected purpose.

Level of scrutiny

Low — this is mechanical, tool-generated output. The appropriate check is consistency verification rather than logic review, and that was done directly against the repo checkout: each bumped package.json version matches its new CHANGELOG heading; the three appended pre.json entries correspond to changeset files that exist on main with frontmatter matching the semver levels applied (minor for client/server/core-internal/core where declared, patch for codemod); dependency-update patch entries (Updated dependencies → @modelcontextprotocol/core@2.0.0-beta.5 etc.) follow the workspace dependency graph correctly. Pre-mode semantics are respected: changeset files are kept and recorded in pre.json rather than deleted.

Other factors

The bug-hunting system found no issues, and the PR timeline has no outstanding reviewer comments. The changelog prose originates from the three source PRs (#2501, #2511, #2513), all merged to main immediately before this Version Packages commit — accuracy of that prose against the implementation was the concern of those PRs' reviews, and this PR transcribes it verbatim without modification. Whether to actually cut the release is a maintainer timing decision, but the content of the PR itself is correct and carries no risk beyond publishing.