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

Minor Changes

• #3047 46d9c99 Thanks @KKonstantinov, @tobi-oye, @mattzcarey! - Add the Skills extension (SEP-2640), reachable through new ext/skills subpaths; package root exports are unchanged.

  • @modelcontextprotocol/server/ext/skills: SkillsExtension (attach(server) serves skills/list, skills/get, resources/directory/read and a skill://{+path} resource template), SkillsExtension.load(files) returning a SkillCatalog with entries and reload(), the SkillFiles storage adapter with memorySkillFiles, SkillSource for generated catalogs, skillEntry, and SkillCatalogError. Invalid skills are skipped with a warning (onWarning), or fail under strict. A file whose bytes are valid UTF-8 is served as text, whatever its MIME type; any other file as a base64 blob.
  • @modelcontextprotocol/server/ext/skills/node: loadSkills(folder) and nodeSkillFiles(folder).
  • @modelcontextprotocol/client/ext/skills: SkillsClient with list() (throws on an invalid entry; skipInvalid: true keeps the valid ones and returns the rest in invalid), get(), read(skill, path?) (size, digest and SKILL.md frontmatter verified, SkillVerificationError on a mismatch; a copy from the response cache that fails a check is fetched once more with cacheMode: 'refresh' first) and readDirectory().
  • @modelcontextprotocol/core/ext/skills: schemas, types and constants, including SKILL_LIMITS. The result schemas follow the stable spec, so ttlMs and cacheScope are required.

  Works on 2025-11-25 and 2026-07-28. On 2026-07-28 only, the server sends the caching fields (ttlMs, cacheScope), and SkillsClient requires them and returns them from list(), get() and readDirectory().

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 [46d9c99]:

  • @modelcontextprotocol/core@2.4.0

@modelcontextprotocol/core@2.4.0

Minor Changes

• #3047 46d9c99 Thanks @KKonstantinov, @tobi-oye, @mattzcarey! - Add the Skills extension (SEP-2640), reachable through new ext/skills subpaths; package root exports are unchanged.

  • @modelcontextprotocol/server/ext/skills: SkillsExtension (attach(server) serves skills/list, skills/get, resources/directory/read and a skill://{+path} resource template), SkillsExtension.load(files) returning a SkillCatalog with entries and reload(), the SkillFiles storage adapter with memorySkillFiles, SkillSource for generated catalogs, skillEntry, and SkillCatalogError. Invalid skills are skipped with a warning (onWarning), or fail under strict. A file whose bytes are valid UTF-8 is served as text, whatever its MIME type; any other file as a base64 blob.
  • @modelcontextprotocol/server/ext/skills/node: loadSkills(folder) and nodeSkillFiles(folder).
  • @modelcontextprotocol/client/ext/skills: SkillsClient with list() (throws on an invalid entry; skipInvalid: true keeps the valid ones and returns the rest in invalid), get(), read(skill, path?) (size, digest and SKILL.md frontmatter verified, SkillVerificationError on a mismatch; a copy from the response cache that fails a check is fetched once more with cacheMode: 'refresh' first) and readDirectory().
  • @modelcontextprotocol/core/ext/skills: schemas, types and constants, including SKILL_LIMITS. The result schemas follow the stable spec, so ttlMs and cacheScope are required.

  Works on 2025-11-25 and 2026-07-28. On 2026-07-28 only, the server sends the caching fields (ttlMs, cacheScope), and SkillsClient requires them and returns them from list(), get() and readDirectory().

@modelcontextprotocol/server@2.4.0

Minor Changes

• #3057 c05225a Thanks @steipete! - ServerEvent takes optional params, which the subscriptions/listen router delivers with its own subscription ID, so a gateway can forward change notifications with their _meta and extension params.

• #3047 46d9c99 Thanks @KKonstantinov, @tobi-oye, @mattzcarey! - Add the Skills extension (SEP-2640), reachable through new ext/skills subpaths; package root exports are unchanged.

  • @modelcontextprotocol/server/ext/skills: SkillsExtension (attach(server) serves skills/list, skills/get, resources/directory/read and a skill://{+path} resource template), SkillsExtension.load(files) returning a SkillCatalog with entries and reload(), the SkillFiles storage adapter with memorySkillFiles, SkillSource for generated catalogs, skillEntry, and SkillCatalogError. Invalid skills are skipped with a warning (onWarning), or fail under strict. A file whose bytes are valid UTF-8 is served as text, whatever its MIME type; any other file as a base64 blob.
  • @modelcontextprotocol/server/ext/skills/node: loadSkills(folder) and nodeSkillFiles(folder).
  • @modelcontextprotocol/client/ext/skills: SkillsClient with list() (throws on an invalid entry; skipInvalid: true keeps the valid ones and returns the rest in invalid), get(), read(skill, path?) (size, digest and SKILL.md frontmatter verified, SkillVerificationError on a mismatch; a copy from the response cache that fails a check is fetched once more with cacheMode: 'refresh' first) and readDirectory().
  • @modelcontextprotocol/core/ext/skills: schemas, types and constants, including SKILL_LIMITS. The result schemas follow the stable spec, so ttlMs and cacheScope are required.

  Works on 2025-11-25 and 2026-07-28. On 2026-07-28 only, the server sends the caching fields (ttlMs, cacheScope), and SkillsClient requires them and returns them from list(), get() and readDirectory().

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.

• #3057 c05225a Thanks @steipete! - Connecting a Server or McpServer to a PerRequestHTTPServerTransport classified at a modern revision that supportedProtocolVersions lists and the SDK implements now binds that revision, instead of answering -32022.

• #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 [46d9c99]:

  • @modelcontextprotocol/core@2.4.0

@modelcontextprotocol/server-legacy@2.4.0

Patch Changes

• Updated dependencies [46d9c99]:
  • @modelcontextprotocol/core@2.4.0

@modelcontextprotocol/codemod@2.4.0

@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 [46d9c99]:

  • @modelcontextprotocol/core@2.4.0

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

[claude]

I reviewed the regenerated 2.4.0 release commit and found no bugs; since merging this is what publishes the Skills extension as a minor release, a maintainer's look is still worthwhile before merging.

What was reviewed:

• Each CHANGELOG entry against the changeset it consumed — the text is reproduced verbatim, and the four linked commits (46d9c99, 43c45f4, b381559, b022522) exist with matching PR numbers.
• Bump levels — core/client/server/server-legacy/codemod all go to 2.4.0 because they form the fixed group in .changeset/config.json; core-internal is outside it and gets the 2.0.5 patch.
• The ext/skills and ext/skills/node subpaths named in the Skills entry are exported by the core, client and server package.json files at this commit.

Extended reasoning...

The commit is the changesets "Version Packages" output: it deletes four pending .changeset files, appends their text to six packages' CHANGELOG.md, and bumps package.json versions (five public packages 2.3.1 -> 2.4.0, private core-internal 2.0.4 -> 2.0.5). No source code changes, so no security-sensitive surface is touched. The changelog prose matches the changeset sources exactly, the commit links resolve, and the bump levels follow from the fixed group configuration. Deferring rather than approving because .github/CODEOWNERS assigns every path to a default owner team and this PR is the release gate for a minor version, which is a maintainer decision rather than a correctness question.

[claude]

Code review found no issues

No high-confidence issues detected in this change.