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

Minor Changes

• #2901 433eb41 Thanks @claude! - The HTTP client transports and the OAuth client helpers now follow a redirect only when it stays within the origin of the request (same scheme, host and port, or http to https on the same host with default ports) and keeps the method (a 307 or 308, or any redirect of a GET). Any other redirect is not followed. A transport then fails the request with an error that names the target; the session is kept and later messages still send. OAuth metadata discovery moves on to the next well-known URL, and any other OAuth request fails with an error that gives the status. Same-origin redirects that keep the method keep working on Node, up to five in a row, and no code changes are needed there. If your endpoint redirects to another origin, configure the transport with the URL it redirects to. A requestInit.redirect of 'error' or 'manual' is passed to fetch as it is for the requests a transport sends to the server (POST, GET and DELETE of the Streamable HTTP transport, POST of the SSE transport); for its OAuth requests, and for any other value, requestInit.redirect is not consulted by default. Browsers do not expose the target of a redirect to a page, so there a redirected request fails instead of being followed. Setting redirectPolicy: 'follow' on a transport leaves its redirects to the fetch implementation, as before this change.

Patch Changes

• #2599 5238fba Thanks @freya0926! - A server can now serve, and a client can now call, tasks/get and tasks/cancel of the Tasks extension (SEP-2663) on a 2026-07-28 connection, when the handler is registered and the request is sent with an explicit schema. Every other method that a protocol revision removed is still refused. If one server factory serves both eras and such a handler is meant for 2025-era clients only, register it only when ctx.era === 'legacy'.

• #2908 633dd3e Thanks @claude! - The license field of the package manifests is now Apache-2.0; the LICENSE file shipped in each package carries the full terms, including the MIT text for earlier contributions. No code change.

• #2903 e765b3b Thanks @claude! - With versionNegotiation in 'auto' or pin mode, a server/discover probe answered with a 2xx that carries no usable reply (a body that
  is not JSON under application/json, a bare 204, a missing or unaccepted content type) still rejects connect() with
  EraNegotiationFailed; an empty SSE stream or a 202 surfaces as the probe timeout instead. The message now says
  the server answered with an unusable reply (...) instead of reading like a network failure. To connect to a 2025 server behind a front that
  answers the probe this way, pass connect(transport, { prior: { kind: 'legacy' } }) or use mode: 'legacy'.

• #2905 c0cd01a Thanks @claude! - SSEClientTransport now retries the SSE connection once after onUnauthorized() resolves, as documented. If the retry is also answered with 401, start() rejects with SdkHttpError (ClientHttpAuthentication) instead of calling onUnauthorized() again. A 401 on a later reconnect of a stream that had opened still gets one refresh.

• Updated dependencies [633dd3e]:

  • @modelcontextprotocol/core@2.3.0

@modelcontextprotocol/server@2.3.0

Minor Changes

• #2907 e55f9ac Thanks @claude! - allowedOrigins and validateOriginHeader accept lowercase entries of the form <scheme>://*, such as moz-extension://* or chrome-extension://*, which admit every origin of that scheme. This lets a server admit MCP clients that run as a browser extension when the extension ID cannot be listed, as on Firefox, where it differs on every install. http://* and https://* are not honoured, and the defaults are unchanged.

Patch Changes

• #2599 5238fba Thanks @freya0926! - A server can now serve, and a client can now call, tasks/get and tasks/cancel of the Tasks extension (SEP-2663) on a 2026-07-28 connection, when the handler is registered and the request is sent with an explicit schema. Every other method that a protocol revision removed is still refused. If one server factory serves both eras and such a handler is meant for 2025-era clients only, register it only when ctx.era === 'legacy'.

• #2889 4d94e7b Thanks @claude! - registerTool no longer converts tool schemas up front, so a server built per request stops converting every tool on every request. The warning about an invalid x-mcp-header declaration now appears each time tools are listed, not when the tool is registered.

• #2908 633dd3e Thanks @claude! - The license field of the package manifests is now Apache-2.0; the LICENSE file shipped in each package carries the full terms, including the MIT text for earlier contributions. No code change.

• #2841 2237555 Thanks @sharziki! - McpServer.registerPrompt() now types the callback correctly when no argsSchema is given: its one parameter is the server context. Before, reading ctx.mcpReq there was a type error although it worked at runtime. Prompts registered with an argsSchema are unchanged.

• Updated dependencies [633dd3e]:

  • @modelcontextprotocol/core@2.3.0

@modelcontextprotocol/codemod@2.3.0

Patch Changes

• #2908 633dd3e Thanks @claude! - The license field of the package manifests is now Apache-2.0; the LICENSE file shipped in each package carries the full terms, including the MIT text for earlier contributions. No code change.

@modelcontextprotocol/core@2.3.0

Patch Changes

• #2908 633dd3e Thanks @claude! - The license field of the package manifests is now Apache-2.0; the LICENSE file shipped in each package carries the full terms, including the MIT text for earlier contributions. No code change.

@modelcontextprotocol/express@2.0.2

Patch Changes

• #2908 633dd3e Thanks @claude! - The license field of the package manifests is now Apache-2.0; the LICENSE file shipped in each package carries the full terms, including the MIT text for earlier contributions. No code change.

• Updated dependencies [5238fba, 4d94e7b, e55f9ac, 633dd3e, 2237555]:

  • @modelcontextprotocol/server@2.3.0

@modelcontextprotocol/fastify@2.0.1

Patch Changes

• #2908 633dd3e Thanks @claude! - The license field of the package manifests is now Apache-2.0; the LICENSE file shipped in each package carries the full terms, including the MIT text for earlier contributions. No code change.

• Updated dependencies [5238fba, 4d94e7b, e55f9ac, 633dd3e, 2237555]:

  • @modelcontextprotocol/server@2.3.0

@modelcontextprotocol/hono@2.0.2

Patch Changes

• #2908 633dd3e Thanks @claude! - The license field of the package manifests is now Apache-2.0; the LICENSE file shipped in each package carries the full terms, including the MIT text for earlier contributions. No code change.

• Updated dependencies [5238fba, 4d94e7b, e55f9ac, 633dd3e, 2237555]:

  • @modelcontextprotocol/server@2.3.0

@modelcontextprotocol/node@2.1.1

Patch Changes

• #2897 7f4c12a Thanks @claude! - hono is now a regular dependency of @modelcontextprotocol/node, so installs with strict peer-dependency checking no longer fail on the hono peer that @hono/node-server requires. No runtime change.

• #2908 633dd3e Thanks @claude! - The license field of the package manifests is now Apache-2.0; the LICENSE file shipped in each package carries the full terms, including the MIT text for earlier contributions. No code change.

• Updated dependencies [5238fba, 4d94e7b, e55f9ac, 633dd3e, 2237555]:

  • @modelcontextprotocol/server@2.3.0

@modelcontextprotocol/server-legacy@2.3.0

Patch Changes

• #2908 633dd3e Thanks @claude! - The license field of the package manifests is now Apache-2.0; the LICENSE file shipped in each package carries the full terms, including the MIT text for earlier contributions. No code change.

• Updated dependencies [633dd3e]:

  • @modelcontextprotocol/core@2.3.0

@modelcontextprotocol/core-internal@2.0.3

Patch Changes

• Updated dependencies [633dd3e]:
  • @modelcontextprotocol/core@2.3.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 finding, I also checked why core and codemod are bumped to 2.2.1 with empty changelog sections — they are in the fixed group in .changeset/config.json with server/client/server-legacy, so they move together by design. The middleware packages are correctly left untouched: their workspace:^ ranges on server still cover 2.2.1.

Extended reasoning...

This is the automated changesets "Version Packages" commit: it deletes one patch changeset, bumps five fixed-group packages 2.2.0 to 2.2.1 and private core-internal 2.0.2 to 2.0.3, and adds matching CHANGELOG headings, with no source changes and no security-sensitive surface. The one inline finding concerns publish ordering of codemod relative to the packages whose versions it inlines, which is a release-process concern rather than an error in the generated metadata; the ruled-out note records the fixed-group and workspace-range checks so a merger does not have to redo them.

[claude]

🟣 pre-existing, not blocking: Users who run the codemod in the window after codemod@ 2.2.1 lands on npm but before server/client/core@ 2.2.1 do, get migrated package.json files whose ^2.2.1 ranges cannot be installed. packages/codemod/src/versions.ts:13-20 inlines the workspace versions at build time, so this bump (packages/codemod/package.json:3) moves the written ranges to ^2.2.1 while nothing orders the publish. Fix: publish codemod after the packages it references (topological ordering or a peer/dependency edge in codemod's package.json), or have the codemod write the previous published minor floor rather than the exact current patch.
A small fix can ride a push you are already making; otherwise a short reply is enough.

Why this was flagged

If pnpm changeset publish in the Release workflow publishes codemod before server, client or core (codemod has no dependency edge on them, packages/codemod/package.json:61-63, so topological order does not constrain it), a user running npx @ modelcontextprotocol/codemod in that window gets @ modelcontextprotocol/server: ^2.2.1 written by packages/codemod/src/versions.ts:15 and npm install fails with no matching version. On the base branch the codemod wrote ^2.2.0, which was already on npm. The dismissing finder called the window pre-existing, but the window only exists because this bump advances the inlined version ahead of what is published; the fixed group in .changeset/config.json:10-18 guarantees same release, not publish order. Population: every codemod user during each release window; remedy: order codemod's publish after its referenced packages or decouple the written range from the exact current patch.

Verification: pre-existing. Triggering condition: a user runs npx @ modelcontextprotocol/codemod in the interval after codemod@ 2.2.1 is on the registry but before server/client/core/server-legacy@ 2.2.1 are (normally seconds, since all publishes run concurrently; longer if one sibling publish fails and needs a re-run). Mechanism verified: packages/codemod/src/versions.ts:13-20 inlines…

[claude]

LGTM — mechanical Changesets "Version Packages" commit, consistent with the repo's changeset config.

What was reviewed:

• The two consumed changesets (server patch, node patch) match the new CHANGELOG entries verbatim, and the linked commits 4d94e7b / 7f4c12a are the two commits directly preceding this one.
• The empty 2.2.1 sections for core/codemod and the dependency-only bumps for client/server-legacy/core-internal follow from the fixed group in .changeset/config.json, so they are expected output rather than missing notes.
• express/hono middleware are correctly left unbumped: they only reference server via workspace:^ peer/dev deps and onlyUpdatePeerDependentsWhenOutOfRange is set; node gets bumped because server is a regular dependency there plus its own changeset.

Extended reasoning...

The diff touches only version fields in seven package.json files, prepends CHANGELOG entries, and deletes the two consumed .changeset files; no source, lockfile, or dependency ranges change, and no security-sensitive surface is involved. The bumps, changelog text, and commit hashes were cross-checked against the deleted changesets, git log, and .changeset/config.json (fixed group and peer-dependent settings), and all are consistent. The change is a bot-generated release commit that follows the established Changesets pattern exactly, which is why approve rather than defer.

Still open from earlier reviews (1):

• Unresolved: 1 minor or pre-existing.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

Still open from earlier reviews (1):

• Unresolved: 1 minor or pre-existing.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

Still open from earlier reviews (1):

• Unresolved: 1 minor or pre-existing.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

Still open from earlier reviews (1):

• Unresolved: 1 minor or pre-existing.

[claude]

LGTM, mechanical changesets release commit.

What was reviewed: the five deleted changesets against the new CHANGELOG entries (text and package attribution match, including the #2904 rewording of the probe entry); the version bumps against .changeset/config.json (core/client/server/server-legacy/codemod move together as the fixed group, node bumps on its own changeset, core-internal on the core dependency); the empty core and codemod 2.2.1 headings as expected fixed-group output; and cross-package dependency ranges, which are all workspace:* / workspace:^ so nothing needs a manual update.

Extended reasoning...

The diff is the single automated "Version Packages" commit: it deletes five patch changesets, folds their text into per-package CHANGELOG.md files, and bumps only the "version" field in seven package.json files. No source, dependency ranges, workflows or security-sensitive surface is touched. Bumps and changelog attribution are consistent with the fixed-group and updateInternalDependencies settings in .changeset/config.json, and the express/hono/fastify adapters correctly stay unbumped because their workspace:^ peer ranges remain in range. The only open item is my earlier pre-existing note about codemod publish ordering, which is not introduced by this PR and does not block a release commit.

Still open from earlier reviews (1):

• Unresolved: 1 minor or pre-existing.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

Still open from earlier reviews (1):

• Unresolved: 1 minor or pre-existing.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

Still open from earlier reviews (1):

• Unresolved: 1 minor or pre-existing.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

Still open from earlier reviews (1):

• Unresolved: 1 minor or pre-existing.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

Still open from earlier reviews (1):

• Unresolved: 1 minor or pre-existing.