Version Packages (beta)#2484
Conversation
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — standard auto-generated changesets release PR.
What was reviewed: the version bumps (client/server beta.3→beta.4, server-legacy beta.2→beta.3) match the package targets declared in the merged lazy-era-wire-schemas changeset from #2476; the CHANGELOG entries reproduce that changeset's text verbatim with correct commit links; and .changeset/pre.json correctly records the consumed changeset. No hand-edits beyond what changesets generates. Whether to merge now is a release-timing call, but the content is mechanically correct.
Extended reasoning...
Overview
This is the auto-generated "Version Packages (beta)" PR from the changesets release action. It touches 7 files: three package.json version bumps (@modelcontextprotocol/client and @modelcontextprotocol/server 2.0.0-beta.3→beta.4, @modelcontextprotocol/server-legacy 2.0.0-beta.2→beta.3), the corresponding CHANGELOG.md entries, and .changeset/pre.json recording the consumed changeset. No source code changes.
Verification against the repository
I cross-checked the diff against .changeset/lazy-era-wire-schemas.md on main: it declares patch for exactly the three packages bumped here, and the CHANGELOG text is a verbatim copy of that changeset's body with a correct link to PR #2476 / commit e0a0ab7 (present in main's recent history). The pre.json addition is alphabetically inserted into the changesets list, consistent with pre-mode bookkeeping. @modelcontextprotocol/core and core-internal are intentionally not bumped — the changeset (authored and reviewed in #2476, already merged) did not target them, and this PR only reflects merged changesets mechanically.
Security risks
None. No executable code is modified; only version metadata and changelog prose. The changelog prose was already reviewed as part of #2476.
Level of scrutiny
Low. This PR is machine-generated by changesets/action from already-merged, already-reviewed changesets — the same shape as previously merged release PRs on this repo (e.g. #2471, commits 2589ff4/95d28cb). Per the repo's review conventions on CI/changesets, the check is that the generated prose matches the merged implementation, which it does verbatim. The only human judgment left is release timing (when to merge/publish), which is orthogonal to correctness of the diff.
Other factors
The bug hunting system found no issues. The PR timeline has no outstanding reviewer comments. The diff is fully deterministic output of the release tooling, so there is no design or correctness surface for a human reviewer to weigh in on.
github-actions
Bot
force-pushed
the
changeset-release/main
branch
from
2589ff4 to
634662c
Compare
There was a problem hiding this comment.
LGTM — mechanical changesets "Version Packages (beta)" PR generated by the release action.
What was reviewed:
- Version bumps match the changeset frontmatter exactly: client/server 2.0.0-beta.3 → beta.4 (both new changesets), server-legacy 2.0.0-beta.2 → beta.3 (only
lazy-era-wire-schemaslists it). .changeset/pre.jsonaddslazy-ajv-engineandlazy-era-wire-schemasto the consumed list, matching the two changeset files present on main.- CHANGELOG entries mirror the changeset prose verbatim and link the already-merged source PRs #2458 and #2476 with correct commit SHAs.
Extended reasoning...
Overview
This is an automated "Version Packages (beta)" PR opened by the changesets release GitHub action. It touches only release bookkeeping: three package.json version fields, three CHANGELOG.md prepends, and the .changeset/pre.json consumed-changesets list. No source code, build config, or workflow files change.
Security risks
None. The diff contains no executable code — only version strings, markdown changelog text, and a JSON list of consumed changeset names. The changelog prose was authored in the already-reviewed source PRs (#2458, #2476), and both referenced commits (7c49b47, e0a0ab7) are on main.
Level of scrutiny
Low. The correctness check for a changesets version PR is mechanical consistency: I verified that lazy-ajv-engine.md declares client+server patch bumps and lazy-era-wire-schemas.md declares client+server+server-legacy patch bumps, which matches exactly the packages bumped and the CHANGELOG entries each package received (server-legacy correctly gets only the wire-schema entry). The pre-mode beta tag increments (beta.3→beta.4, beta.2→beta.3) are the expected prerelease bumps, and pre.json gains exactly the two new changeset names in sorted order.
Other factors
The bug hunting system found no issues, and the PR timeline has no outstanding reviewer comments. Per the repo's own review conventions, CI/release-toolchain output should not be second-guessed without evidence — and here the changesets action output is internally consistent in every checkable dimension. Merging this publishes prerelease versions, which is the maintainers' call on timing, but the content of the diff itself is correct and needs no human line-by-line review.
github-actions
Bot
force-pushed
the
changeset-release/main
branch
from
634662c to
379cbd5
Compare
There was a problem hiding this comment.
LGTM — machine-generated changesets release PR (Version Packages, beta pre-mode); no hand-written code changes.
What was reviewed:
- The three new pre.json changeset entries (
lazy-ajv-engine,lazy-era-wire-schemas,schemas-source-home) match merged PRs #2458 / #2476 / #2477, whose commits (7c49b47, e0a0ab7, 8e1d2e9) are on main, and the corresponding.changeset/*.mdfiles exist. - Version bumps are consistent with changesets pre-mode: publishable packages → 2.0.0-beta.4, private core-internal → 2.0.0-beta.3; server-legacy jumping beta.2 → beta.4 is the expected shared-tag counter (it had no beta.3 release).
- CHANGELOG entries are verbatim copies of the already-reviewed changeset prose from the source PRs; no new claims introduced in this diff.
Extended reasoning...
Overview
PR #2484 is the standard "Version Packages (beta)" PR opened automatically by the changesets/action bot. It touches 19 files: nine package.json version fields, nine CHANGELOG.md files (prepending the new release sections), and .changeset/pre.json (recording three newly-consumed changesets: lazy-ajv-engine, lazy-era-wire-schemas, schemas-source-home). There is no source code in the diff.
Security risks
None. The diff contains only version strings, changelog markdown, and the pre-mode changeset ledger. No runtime code, dependencies, auth surfaces, or CI workflow files are modified. The dependency graph entries in the changelogs are informational text, not manifest changes.
Level of scrutiny
Low — this is exactly the class of mechanical, tool-generated change the approval guidelines call out as approvable. The appropriate check is consistency rather than logic review: I confirmed the three referenced source PRs (#2458, #2476, #2477) are merged to main (commits 7c49b47, e0a0ab7, 8e1d2e9 appear in recent history), the changeset files named in pre.json exist on disk, and the version numbers follow changesets pre-mode semantics (all publishable packages at 2.0.0-beta.4; the private core-internal at 2.0.0-beta.3; server-legacy skipping beta.3 because it shipped nothing in that release while the pre-tag counter is shared across the fixed group). The changelog prose is a verbatim copy of the changeset text that was already reviewed as part of the source PRs, so the repo convention about checking changeset prose against implementation was discharged there — this PR introduces no new claims.
Other factors
The bug-hunting system found no issues, and the PR timeline shows no outstanding reviewer comments. Merging this PR is the routine release step; if anything were wrong in the underlying changesets it would be a problem with the already-merged source PRs, not with this generated diff. The bot keeps the PR updated as new changesets land, so approval reflects the current snapshot.
github-actions
Bot
force-pushed
the
changeset-release/main
branch
from
379cbd5 to
cf3b0ab
Compare
There was a problem hiding this comment.
LGTM — this is the auto-generated changesets "Version Packages (beta)" release PR; all content is machine-generated and internally consistent.
What was reviewed:
- Version bumps: the fixed group (core/client/server/server-legacy) all move to 2.0.0-beta.4 — server-legacy skipping beta.3 is correct changesets fixed-group behavior per .changeset/config.json, not an error; middleware packages get the expected dependency-driven patch bumps and private core-internal moves to beta.3.
- .changeset/pre.json adds exactly the four new changeset names (lazy-ajv-engine, lazy-era-wire-schemas, schemas-source-home, workerd-schema-preload), matching the .md files still present on disk (kept, not deleted, as pre mode requires).
- CHANGELOG entries are verbatim copies of the already-merged changesets from #2458, #2476, #2477, #2483 with correct PR/commit links.
Extended reasoning...
Overview
This PR was opened by the changesets/action bot and contains only release mechanics: version fields in nine package.json files, auto-generated CHANGELOG.md entries assembled from four already-merged changesets (#2458, #2476, #2477, #2483), and the pre-mode ledger update in .changeset/pre.json. No source code, build config, or CI is touched.
Security risks
None. The diff contains no executable code changes — only version strings and prose changelog entries copied from changesets that were reviewed in their originating PRs. The only downstream effect of merging is triggering the (pre-mode beta) npm publish, which is the PR's stated purpose.
Level of scrutiny
Low. The correct check for a Version Packages PR is internal consistency, which I verified: the fixed version group in .changeset/config.json ([core, client, server, server-legacy]) explains server-legacy jumping from beta.2 straight to beta.4; updateInternalDependencies: 'patch' explains the middleware packages' patch bumps; core-internal (private) correctly bumps to beta.3 on its own counter; pre.json's changeset list gains exactly the four new changeset filenames present in .changeset/; and the changeset .md files are correctly retained rather than deleted, per pre-mode semantics. CHANGELOG prose matches the source changesets verbatim.
Other factors
The bug hunting system found no issues. There are no reviewer comments or outstanding discussion on the PR. This class of PR is routinely merged without line-by-line human review once the constituent changesets have been reviewed in their own PRs, which they were.
github-actions
Bot
force-pushed
the
changeset-release/main
branch
from
cf3b0ab to
dae0a44
Compare
There was a problem hiding this comment.
LGTM — this is a mechanical changesets-generated release PR (beta.3 → beta.4), and the diff matches what the tooling should produce from the five new changesets. The one inline nit (codemod left at beta.3 outside the fixed group) is worth a quick follow-up but doesn't block the release.
Extended reasoning...
Overview
This is the standard Version Packages (beta) PR opened by the changesets action. It bumps the eight published packages (client, core, server, server-legacy, express, fastify, hono, node) to 2.0.0-beta.4, bumps the private core-internal to 2.0.0-beta.3, appends the corresponding CHANGELOG entries, and records the five newly-consumed changesets (lazy-ajv-engine, lazy-era-wire-schemas, response-cache-document-codec, schemas-source-home, workerd-schema-preload) in .changeset/pre.json. No source code is touched.
Verification performed
I cross-checked the diff against the changesets machinery: the five new pre.json entries match the five changeset files and the five PRs referenced in the changelogs (#2458, #2468, #2476, #2477, #2483); the changelog prose is a verbatim copy of the changeset files from those already-reviewed PRs; the fixed group in .changeset/config.json (core/client/server/server-legacy) explains server-legacy jumping beta.2 → beta.4 in one step, repairing the prior version skew; and the middleware packages correctly receive dependency-only patch bumps. The one discrepancy found — @modelcontextprotocol/codemod staying at beta.3 because it has no changeset this round and is not in the fixed group — is real and is flagged inline; it only affects users who hand-pin the codemod at the exact shared version against the migration guide's advice, so it is a nit, not a blocker.
Security risks
None. The diff consists solely of version strings, changelog markdown, and the changesets bookkeeping file. No runtime code, auth, crypto, or CI configuration changes.
Level of scrutiny
Low for content correctness — the diff is deterministic tool output, and every substantive change it describes was reviewed in its originating PR. The release decision itself (when to merge and publish) remains with the maintainers regardless of this approval.
Other factors
No prior reviews or comments on the PR; nothing outstanding to address. The changelog claims were checked against the implementation in their source PRs per repo convention (Documentation & Changesets recurring catch), and the only prose-vs-reality gap found is the codemod version-drift nit already posted inline.
github-actions
Bot
force-pushed
the
changeset-release/main
branch
from
dae0a44 to
a64aec6
Compare
@modelcontextprotocol/client
@modelcontextprotocol/codemod
@modelcontextprotocol/core
@modelcontextprotocol/server
@modelcontextprotocol/server-legacy
@modelcontextprotocol/express
@modelcontextprotocol/fastify
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
There was a problem hiding this comment.
LGTM — machine-generated Version Packages PR, and the codemod version drift I flagged on the previous revision is now resolved: @modelcontextprotocol/codemod joined the fixed group via #2486 and this regenerated PR bumps it to 2.0.0-beta.4 with the rest.
What was reviewed
- All five fixed-group packages (core, client, server, server-legacy, codemod) land at
2.0.0-beta.4; server-legacy's beta.2 → beta.4 jump is the expected fixed-group catch-up. - Middleware packages (express, fastify, hono, node) and private core-internal receive the correct dependency-cascade patch bumps.
- The six new
.changeset/pre.jsonentries match the consumed changesets (#2458, #2468, #2476, #2477, #2483, #2486), and each CHANGELOG section reproduces its changeset verbatim.
Extended reasoning...
Overview
This is a changesets-action-generated "Version Packages (beta)" PR: 21 files, all of them package.json version bumps, CHANGELOG.md prepends, and the .changeset/pre.json consumed-changesets ledger. No source code changes. It releases 2.0.0-beta.4 for the fixed group (core, client, server, server-legacy, codemod) plus dependency-cascade bumps for the middleware packages and the private core-internal.
Prior review state
On the previous revision of this PR I flagged that the codemod was left at 2.0.0-beta.3 while everything else moved to beta.4, contradicting the migration guide's shared-version guarantee. That was addressed: #2486 (codemod-fixed-group changeset) added @modelcontextprotocol/codemod to the fixed group in .changeset/config.json — verified in the repo — and the regenerated PR now bumps the codemod to 2.0.0-beta.4 with a CHANGELOG entry explaining the alignment. Nothing from my prior feedback remains outstanding.
Security risks
None. The diff contains only version strings and changelog prose generated from already-merged changesets; no runtime code, auth, or transport logic is touched. Merging triggers an npm publish, but the publish content is the already-reviewed main history.
Level of scrutiny
Low-to-moderate. The generated content itself is mechanical; the real review surface for a Version Packages PR is versioning-policy consistency, which I checked: fixed-group members all at beta.4 (server-legacy correctly skipping a never-published beta.3), cascade bumps correct, pre.json additions matching the retained changeset files (pre mode keeps the .md files on disk), and CHANGELOG entries tracing one-to-one to the source PRs (#2458, #2468, #2476, #2477, #2483, #2486).
Other factors
The bug hunting system found no issues this run. One non-issue noted and deliberately not flagged: the #2477 changeset prose says "the four packages now version together" while the group is now five with the codemod — that text is a verbatim quote of an already-merged changeset written before #2486, not something this PR authored, so it does not warrant blocking a generated release PR.
1 participant
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.
mainis currently in pre mode so this branch has prereleases rather than normal releases. If you want to exit prereleases, runchangeset pre exitonmain.Releases
@modelcontextprotocol/client@2.0.0-beta.4
Minor Changes
#2468
5db6e38Thanks @felixweinberger! - The response cache now stores results as JSON-serialized documents (serialize on write, parse on read) instead of live object graphs isolated withstructuredClone. Same mutation isolation, but no dependency on thestructuredCloneglobal — whose absence (jest+jsdom, Node < 17) previously made every cache write throw into the store-error swallow, silently disabling caching and output-schema lookups for the session. A value without a JSON representation now fails the write loudly to the error sink, and an undecodable document in an external store is reported, dropped, and read as a miss.Migration for custom
ResponseCacheStoreimplementations:CacheEntry.value(and theset()entry value) is nowstring— persist and return it verbatim,JSON.parseto inspect. Entries persisted by a previous SDK version fail decode once (reported, dropped) and are rewritten on the next fetch.#2477
8e1d2e9Thanks @felixweinberger! - Move the schema source modules (spec schemas, OAuth schemas, protocol constants) into@modelcontextprotocol/coreand resolve them from there as a regular runtime dependency instead of bundling a private copy into each package. An application importing more than one of the packages now evaluates a single shared schema graph with shared object identity.@modelcontextprotocol/coregains a./internalsubpath (SDK-internal contract; may change in any release) and the four packages now version together.#2483
3f07a32Thanks @felixweinberger! - AddpreloadSchemas(), an explicit opt-in to eager wire-schema construction, and call it automatically in the Cloudflare Workers builds. The wire schemas are built lazily by default, which is the right trade on process-per-invocation runtimes — but on isolate platforms that bill request CPU while module evaluation runs during isolate warm-up, laziness moves construction into the first request each fresh isolate serves. CallingpreloadSchemas()at module scope (it is synchronous and idempotent) moves that one-time cost back to module evaluation; the packages' workerd export condition now does this automatically, while the Node and browser builds stay lazy. The server package gains a dedicated browser shim for this (itsbrowsercondition previously reused the workerd shim), so browser bundles keep lazy construction.Patch Changes
#2458
7c49b47Thanks @felixweinberger! - Construct the default Ajv validation engine lazily on first validation. Creating aClientorServerno longer pays the ajv + ajv-formats instantiation cost at startup when no JSON Schema validation ever runs.#2476
e0a0ab7Thanks @felixweinberger! - Build protocol-revision wire schemas lazily on first validation instead of at import. Each revision's schema set is now constructed by a module-level memoized factory, so importing the client or server package no longer pays the construction cost of both frozen wire-schema graphs up front. Method membership in the revision registries stays static, the schemas themselves are unchanged, and registry lookups keep returning reference-identical schema objects.Updated dependencies [
8e1d2e9]:@modelcontextprotocol/core@2.0.0-beta.4
Minor Changes
8e1d2e9Thanks @felixweinberger! - Move the schema source modules (spec schemas, OAuth schemas, protocol constants) into@modelcontextprotocol/coreand resolve them from there as a regular runtime dependency instead of bundling a private copy into each package. An application importing more than one of the packages now evaluates a single shared schema graph with shared object identity.@modelcontextprotocol/coregains a./internalsubpath (SDK-internal contract; may change in any release) and the four packages now version together.@modelcontextprotocol/server@2.0.0-beta.4
Minor Changes
#2477
8e1d2e9Thanks @felixweinberger! - Move the schema source modules (spec schemas, OAuth schemas, protocol constants) into@modelcontextprotocol/coreand resolve them from there as a regular runtime dependency instead of bundling a private copy into each package. An application importing more than one of the packages now evaluates a single shared schema graph with shared object identity.@modelcontextprotocol/coregains a./internalsubpath (SDK-internal contract; may change in any release) and the four packages now version together.#2483
3f07a32Thanks @felixweinberger! - AddpreloadSchemas(), an explicit opt-in to eager wire-schema construction, and call it automatically in the Cloudflare Workers builds. The wire schemas are built lazily by default, which is the right trade on process-per-invocation runtimes — but on isolate platforms that bill request CPU while module evaluation runs during isolate warm-up, laziness moves construction into the first request each fresh isolate serves. CallingpreloadSchemas()at module scope (it is synchronous and idempotent) moves that one-time cost back to module evaluation; the packages' workerd export condition now does this automatically, while the Node and browser builds stay lazy. The server package gains a dedicated browser shim for this (itsbrowsercondition previously reused the workerd shim), so browser bundles keep lazy construction.Patch Changes
#2458
7c49b47Thanks @felixweinberger! - Construct the default Ajv validation engine lazily on first validation. Creating aClientorServerno longer pays the ajv + ajv-formats instantiation cost at startup when no JSON Schema validation ever runs.#2476
e0a0ab7Thanks @felixweinberger! - Build protocol-revision wire schemas lazily on first validation instead of at import. Each revision's schema set is now constructed by a module-level memoized factory, so importing the client or server package no longer pays the construction cost of both frozen wire-schema graphs up front. Method membership in the revision registries stays static, the schemas themselves are unchanged, and registry lookups keep returning reference-identical schema objects.Updated dependencies [
8e1d2e9]:@modelcontextprotocol/server-legacy@2.0.0-beta.4
Minor Changes
8e1d2e9Thanks @felixweinberger! - Move the schema source modules (spec schemas, OAuth schemas, protocol constants) into@modelcontextprotocol/coreand resolve them from there as a regular runtime dependency instead of bundling a private copy into each package. An application importing more than one of the packages now evaluates a single shared schema graph with shared object identity.@modelcontextprotocol/coregains a./internalsubpath (SDK-internal contract; may change in any release) and the four packages now version together.Patch Changes
#2476
e0a0ab7Thanks @felixweinberger! - Build protocol-revision wire schemas lazily on first validation instead of at import. Each revision's schema set is now constructed by a module-level memoized factory, so importing the client or server package no longer pays the construction cost of both frozen wire-schema graphs up front. Method membership in the revision registries stays static, the schemas themselves are unchanged, and registry lookups keep returning reference-identical schema objects.Updated dependencies [
8e1d2e9]:@modelcontextprotocol/codemod@2.0.0-beta.4
Patch Changes
ee8267aThanks @felixweinberger! - Version the codemod together with the core SDK packages, matching the migration guide's shared-version guarantee.@modelcontextprotocol/express@2.0.0-beta.4
Patch Changes
7c49b47,e0a0ab7,8e1d2e9,3f07a32]:@modelcontextprotocol/fastify@2.0.0-beta.4
Patch Changes
7c49b47,e0a0ab7,8e1d2e9,3f07a32]:@modelcontextprotocol/hono@2.0.0-beta.4
Patch Changes
7c49b47,e0a0ab7,8e1d2e9,3f07a32]:@modelcontextprotocol/node@2.0.0-beta.4
Patch Changes
7c49b47,e0a0ab7,8e1d2e9,3f07a32]:@modelcontextprotocol/core-internal@2.0.0-beta.3
Patch Changes
8e1d2e9]: