Version Packages (beta) - #2512
Conversation
Sorry, something went wrong.
There was a problem hiding this comment.
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.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM — standard machine-generated changesets "Version Packages" release PR (pre mode, beta tag); no hand-written code changes.
What was reviewed:
- Version bumps are internally consistent: all public packages move beta.4 → beta.5, and the private core-internal moves beta.3 → beta.4, matching pre-mode expectations.
- The four names added to .changeset/pre.json (export-protocol-class, prior-legacy-verdict, probe-close-handling, spec-3002-servinfo-meta) each correspond to an existing changeset file and are inserted in sorted order.
- CHANGELOG entries are verbatim copies of those changesets and reference the correct source PRs (#2501, #2511, #2513, #2514); dependency-update entries fan out to the right dependents (server → middleware adapters, core → client/server/server-legacy/core-internal).
Overview
PR #2512 is the changesets-action-generated "Version Packages (beta)" PR. It touches 21 files: 10 package.json version fields, 10 CHANGELOG.md prepends, and .changeset/pre.json (recording the four newly consumed changesets in pre mode). There are zero source-code changes — every line is generated by changeset version.
Security risks
None. The diff contains no executable code, no dependency additions or range changes (all inter-package deps use the workspace: protocol, so no manifest dependency edits were needed), and no workflow changes. The CHANGELOG text is copied verbatim from changeset files already merged to main via their own reviewed PRs.
Level of scrutiny
Low. The correct check for a Version Packages PR is internal consistency, which I verified: (1) all public packages bump beta.4 → beta.5 while the private @modelcontextprotocol/core-internal bumps beta.3 → beta.4 (it versions on its own cadence and only bumped now because it received changesets); (2) the four names added to pre.json's changesets array match the four changeset files present on the branch and are inserted in correct alphabetical positions; (3) each CHANGELOG entry cites the correct originating PR/commit and the "Updated dependencies" fan-out matches the dependency graph (middleware packages depend on server; client/server/server-legacy/core-internal depend on core). Merging this publishes beta prereleases, but the release content itself was reviewed in the underlying feature PRs.
Other factors
The bug hunting system found no issues, the PR timeline has no human comments or outstanding review threads, and main's HEAD already carries this exact commit shape, consistent with the repo's established release cadence (beta.1 through beta.4 followed the same pattern). Nothing here warrants a human diff-read.
Sorry, something went wrong.
|
@modelcontextprotocol/client
npm i https://pkg.pr.new/@modelcontextprotocol/client@2512
npm i https://pkg.pr.new/@modelcontextprotocol/codemod@2512
npm i https://pkg.pr.new/@modelcontextprotocol/core@2512
npm i https://pkg.pr.new/@modelcontextprotocol/server@2512
npm i https://pkg.pr.new/@modelcontextprotocol/server-legacy@2512
npm i https://pkg.pr.new/@modelcontextprotocol/express@2512
npm i https://pkg.pr.new/@modelcontextprotocol/fastify@2512
npm i https://pkg.pr.new/@modelcontextprotocol/hono@2512
npm i https://pkg.pr.new/@modelcontextprotocol/node@2512 commit: da4653d |
Sorry, something went wrong.
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:
Patch Changes
#2514 6fe1963 Thanks @felixweinberger! - Probe stdio servers on a disposable sibling process. Some stdio servers exit on any pre-initialize request (servers built on the official Rust SDK, rmcp, behave this way), so under versionNegotiation: { mode: 'auto' } the server/discover probe previously killed the server and connect() hard-failed. The probe now runs on a short-lived sibling spawned from the same parameters — its stderr is discarded and it is reaped once the era is known — and the caller's transport spawns exactly once, afterwards: a legacy verdict connects with the plain initialize handshake (byte-identical to mode: 'legacy'), a modern verdict is adopted directly, and the session wire never carries server/discover. Closing the caller's transport during the probe aborts connect() with the typed SdkError(EraNegotiationFailed) and the session child is never spawned. On HTTP — and on custom stdio-shaped transports, which probe in place — a mid-probe connection close keeps rejecting with the typed connect error, now naming the close in pin-mode and modern-only diagnostics.
Updated dependencies [f413763]:
@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:
@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:
Patch Changes
@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
@modelcontextprotocol/fastify@2.0.0-beta.5
Patch Changes
@modelcontextprotocol/hono@2.0.0-beta.5
Patch Changes
@modelcontextprotocol/node@2.0.0-beta.5
Patch Changes
@modelcontextprotocol/server-legacy@2.0.0-beta.5
Patch Changes
@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:
Patch Changes