Version Packages

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

Patch Changes

• #2762 b022522 Thanks @pcarleton! - x-mcp-header on a number-typed tool parameter is now rejected, matching the 2026-07-28 spec ("Parameters with type number are not permitted"; clients MUST exclude such tools from tools/list). Previously number was accepted only to satisfy an older conformance fixture that has since been corrected. integer, string and boolean are unaffected.

• Updated dependencies []:

  • @modelcontextprotocol/core@2.3.2

@modelcontextprotocol/server@2.3.2

Patch Changes

• #2960 43c45f4 Thanks @claude! - A server whose tool puts x-mcp-header on a number-typed parameter keeps checking that tool's Mcp-Param-* headers on tools/call, as 2.3.0 does: a header that is missing for a value in the body, or that disagrees with the body, is answered 400 with JSON-RPC error -32020. Clients on a 2026-07-28 connection other than stdio no longer list such a tool and send no Mcp-Param-* headers for it, so a call that carries a value for a declared parameter is rejected the same way; the server logs a warning each time tools are listed. Use an integer (z.int()) or remove the annotation.

• #3005 b381559 Thanks @chaeyn! - Reflect resource and resource template update({ title }) changes in list responses. Preserve other metadata and individual resource titles when a template supplies list entries.

• #2762 b022522 Thanks @pcarleton! - x-mcp-header on a number-typed tool parameter is now rejected, matching the 2026-07-28 spec ("Parameters with type number are not permitted"; clients MUST exclude such tools from tools/list). Previously number was accepted only to satisfy an older conformance fixture that has since been corrected. integer, string and boolean are unaffected.

• Updated dependencies []:

  • @modelcontextprotocol/core@2.3.2

@modelcontextprotocol/server-legacy@2.3.2

Patch Changes

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

@modelcontextprotocol/codemod@2.3.2

@modelcontextprotocol/core@2.3.2

@modelcontextprotocol/core-internal@2.0.5

Patch Changes

• #2762 b022522 Thanks @pcarleton! - x-mcp-header on a number-typed tool parameter is now rejected, matching the 2026-07-28 spec ("Parameters with type number are not permitted"; clients MUST exclude such tools from tools/list). Previously number was accepted only to satisfy an older conformance fixture that has since been corrected. integer, string and boolean are unaffected.

• Updated dependencies []:

  • @modelcontextprotocol/core@2.3.2

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

Beyond the inline note, I also checked the empty core and codemod 2.3.2 entries and the lockstep bump of all five public packages — that is the expected output of the fixed group in .changeset/config.json, not a stray changeset. Inter-package dependencies all use workspace:* / workspace:^, so the version bumps leave no range to drift.

Extended reasoning...

Automated Version Packages commit: deletes one changeset and bumps versions plus CHANGELOG entries across six packages, with no source changes and no security-sensitive surface. The lockstep bump and empty headings follow from the fixed-group config, and workspace protocol dependencies make the bump self-consistent; the only open point is the inline changelog-wording finding.

[claude]

LGTM — mechanical Changesets release commit, now also carrying the #3005 entry since the last push.

What was reviewed:

• Both consumed changesets match the generated CHANGELOG entries verbatim, and the #3005 entry's commit link points at the actual merge commit (b381559).
• Version bumps follow .changeset/config.json: the fixed group (core, client, server, server-legacy, codemod) moves together to 2.3.2, so core and codemod correctly get empty headings; core-internal is outside the group and goes 2.0.4 -> 2.0.5 on its own changeset.
• Inter-package ranges are all workspace:* / workspace:^, so no range edits were needed; core-internal does depend on core, so its "Updated dependencies" line is accurate. Middleware packages reference server only as peer/dev deps with ^, which stays in range for a patch bump, matching onlyUpdatePeerDependentsWhenOutOfRange and the previous release commit (fcef852).

Extended reasoning...

The diff is the github-actions Version Packages commit: it deletes two changeset files, bumps version fields in six package.json files (five fixed-group packages 2.3.1 -> 2.3.2, private core-internal 2.0.4 -> 2.0.5) and prepends generated CHANGELOG entries; no source code changes and no security-sensitive surface. The file set and structure are identical to the prior release commit fcef852, and the version/dependency bookkeeping was checked against .changeset/config.json and each package's dependency declarations. The only open thread is my own earlier optional nit on the server changelog wording, which remains unchanged text and does not affect correctness of the release mechanics; the bug hunt ran dry with no new findings.

Still open from earlier reviews (1):

• Unresolved: 1 minor or pre-existing.

[claude]

I reviewed the updated Version Packages PR and found no bugs; since this is the release commit and every path is CODEOWNER-owned, a maintainer should still decide when to merge and publish.

What was reviewed:

• The three consumed changesets against the new CHANGELOG sections — each entry is a verbatim copy, and the package lists match which CHANGELOGs received entries.
• The 2.3.2 bump across core, client, server, server-legacy and codemod matches the fixed group in .changeset/config.json; core-internal moves to 2.0.5 on its own changeset. Middleware packages are correctly untouched (workspace:^ peers, onlyUpdatePeerDependentsWhenOutOfRange).
• The new #2960 entry in packages/server/CHANGELOG.md against commit 43c45f4: the scanner now returns declarations for a number-only fault and createMcpHandler.ts keeps validating Mcp-Param-* for that tool, so the entry describes what the server does.

Extended reasoning...

The commit is Changesets output only: three changeset files deleted, six package.json version bumps, and six CHANGELOG.md additions, with no source changes. It touches no auth, injection or data-exposure surface. The version bumps follow the fixed-group configuration and all internal dependencies use the workspace: protocol, so ranges resolve. Since my prior review, commit 43c45f4 added the #2960 changeset whose text now states the server-side behavior accurately, which is what the earlier inline nit asked for. The .github/CODEOWNERS file assigns every path to a team, and a release PR is merged by a maintainer by design, so defer rather than approve.