Introduce @modelcontextprotocol/core as the public home for the MCP specification and OAuth/OpenID Zod schemas, and teach the v1→v2 codemod to migrate schema usage to it — plus several codemod accuracy and correctness fixes surfaced by running the migration against real-world v1 repos and by code review. This PR also renames the private internal barrel @modelcontextprotocol/core → core-internal, freeing the clean core name for the public schema package (published in alpha as @modelcontextprotocol/sdk-shared).

Motivation and Context

In v2, @modelcontextprotocol/server and @modelcontextprotocol/client deliberately expose a Zod-free public surface. That left the raw spec Zod schemas (CallToolResultSchema, ListToolsResultSchema, …) — which v1 users imported from @modelcontextprotocol/sdk/types.js — with no public home. Code that did runtime validation like CallToolResultSchema.safeParse(value) had nowhere to import the schema from after migrating, and the codemod's previous workaround rewrote those calls into the Standard-Schema form (specTypeSchemas.X['~standard'].validate(...)), which changed user code more than necessary. The same gap applied to the OAuth/OpenID schemas (OAuthTokensSchema, OAuthMetadataSchema, …) that v1 exposed from @modelcontextprotocol/sdk/shared/auth.js.

This PR closes that gap and tightens the migration:

• New package @modelcontextprotocol/core — the canonical, public home for the spec Zod schemas and the OAuth/OpenID auth schemas (OAuthTokensSchema, OAuthMetadataSchema, IdJagTokenExchangeResponseSchema, …). It bundles the SDK's internal schema definitions and re-exports only the *Schema Zod constants, so <Name>Schema.parse(value) / .safeParse(value) keep working unchanged — the migration becomes a one-line import-path swap. The auth group mirrors core-internal's own spec-vs-auth split and is kept in sync with core-internal's authSchemas registry by a drift-guard test. Spec types, error classes, enums, and guards continue to live on server/client. The package is runtime-neutral with zod as its only runtime dependency.
• Package rename (core → core-internal, sdk-shared → core). The private, unpublished internal barrel formerly named @modelcontextprotocol/core becomes @modelcontextprotocol/core-internal, freeing the clean core name for the public schema package above (published in alpha as @modelcontextprotocol/sdk-shared). A repo-wide, behavior-preserving rename of two packages and their directories — client/server/middleware now consume the internal barrel under its new name. Recorded for the changelog by the rename-sdk-shared-to-core changeset.
• Codemod: route schema imports to core. *Schema symbols imported from @modelcontextprotocol/sdk/types.js are now routed to @modelcontextprotocol/core (a mixed import { CallToolResult, CallToolResultSchema } is split — the type resolves by context, the schema to core). The v1 OAuth/OpenID *Schema constants from @modelcontextprotocol/sdk/shared/auth.js are routed the same way (the auth types keep resolving to client/server by context). The old specSchemaAccess transform and its generated schema-map are removed in favor of this behavior-preserving import swap.
• Codemod accuracy fixes (found by running the batch test against firebase/firebase-tools):
  • Match extensionless SDK subpath specifiers (e.g. @modelcontextprotocol/sdk/types as well as .../types.js).
  • Infer client/server project type from source for v1 projects. A project mid-migration still declares the single v1 @modelcontextprotocol/sdk dependency, so detection from package.json came back "unknown" and every file importing only shared symbols defaulted to the server package with an action-required warning. The codemod now scans quoted @modelcontextprotocol/sdk/client/… and …/server/… import specifiers to infer the type, routing shared symbols to the installed package and replacing the spurious warnings with — at most — an info note for genuinely ambiguous "both" projects.
  • Map the task request/notification handlers (tasks/get, tasks/result, tasks/list, tasks/cancel, notifications/tasks/status) to their v2 method strings so task handlers migrate to the 2-arg form instead of falling through to manual migration.
  • Flag namespace-imported schema usage (import * as t … t.CallToolResultSchema.parse()), which can't be split automatically, with an actionable diagnostic pointing at core. The diagnostic now reports the v2 schema name (after renames) so the suggested import is copy-pasteable.
• Codemod correctness fixes (code review):
  • Guard the schema-param removal so a literal undefined second argument is only dropped in files that actually import the MCP SDK (avoids touching unrelated 3-arg calls).
  • Capture a removed import's leading file-header/JSDoc comment as exact source bytes (not a \n-rejoin of comment ranges), so CRLF files and blank-line-separated header blocks no longer duplicate the header when the first import is rewritten in place.
• @modelcontextprotocol/core ↔ client/server consistency. Registering the auth schemas as the canonical core group is keyed off core-internal's authSchemas. The one v2-only addition, IdJagTokenExchangeResponse, is now a public spec type: its TypeScript type is exported from client/server, 'IdJagTokenExchangeResponse' joins SpecTypeName, and isSpecType.IdJagTokenExchangeResponse / specTypeSchemas.IdJagTokenExchangeResponse validate it — matching the already-public OAuth/OpenID spec types. This additive (non-breaking) surface is covered by a client/server changeset.
• Migration docs updated to describe the schema-validation path (import from core; .parse() unchanged), with the Zod-free isSpecType / specTypeSchemas as an alternative; OAuth/OpenID schemas are noted as also moving to core.

How Has This Been Tested?

• Unit tests: the codemod suite passes (spec + OAuth/OpenID import routing, schema→method mapping, project-type inference incl. comment/extensionless edge cases, namespace-import diagnostics, leading-comment preservation incl. CRLF/blank-line headers), plus core tests (schema round-trip + drift guards asserting every spec and auth schema is re-exported). Three drift guards keep the auth set aligned: core's auth exports equal core-internal's authSchemas, and the codemod's AUTH_SCHEMA_NAMES (the v1 set) is a subset of core's auth exports.
• Full monorepo gate: build:all, check:all (typecheck + lint + docs) all green. The core bundle was verified runtime-neutral — zod external, no Node built-ins, no Protocol/transport/validator code pulled in, and the .d.ts exposes the schemas as real values (not type-only aliases).
• End-to-end on a real repo: the codemod batch test against firebase/firebase-tools — baseline typecheck 0 errors, post-codemod typecheck 0 errors (0 introduced). After the accuracy fixes, the codemod's diagnostics on that repo dropped to just the two genuinely-actionable manual-verification notes (SSE-transport deprecation, ErrorCode split). Spot-checked the migrated output: schemas import from @modelcontextprotocol/core and .parse() calls are preserved verbatim.

Breaking Changes

None for existing v2 consumers. @modelcontextprotocol/core is a new, additive package. server and client gain one small additive (non-breaking) public-API surface — the v2-only IdJagTokenExchangeResponse spec type (type export + SpecTypeName member + isSpecType/specTypeSchemas entry), covered by a client/server changeset; the private core-internal package registers it. The middleware packages are unchanged. The package rename is invisible to stable consumers: the internal barrel (core → core-internal) was always private and unpublished, and the only public-name change — the alpha @modelcontextprotocol/sdk-shared → @modelcontextprotocol/core — affects only those who installed the alpha schema package, who update with a one-line import swap (sdk-shared → core) that the codemod applies automatically (rename-sdk-shared-to-core changeset). The schema-import-location change core supports is part of the existing v1→v2 migration (not new breakage) and is applied automatically by the codemod and documented in the migration guide.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

• Why core bundles core-internal rather than owning the schemas. An alternative was prototyped where core owned the schemas and server/client referenced it externally to avoid duplicating the schema bytes. It worked but was invasive (it touched core-internal/server/client/middleware build configs and required guarding against a rolldown value-export degradation). This PR takes the lower-footprint approach: core bundles the (private) core-internal schema module via a narrowed alias and re-exports only the *Schema values, leaving server/client's build and schema-bundling untouched (their only public-API delta is the additive IdJagTokenExchangeResponse spec type noted above). The trade-off is that server/client keep their own internally-bundled schema copies (not part of their public API) — an accepted cost for a much smaller, lower-risk change.
• Project-type inference / task-handler mapping adopt the approach from PR Improve v1→v2 migration ergonomics: Zod-compatible specTypeSchemas + codemod fixes #2277 (thanks @felixweinberger). The project-type inference here refines it to match quoted import specifiers rather than whole-file substrings, so paths mentioned in comments/prose don't cause false positives, and it also recognizes extensionless/bare subpaths.
• The codemod's "could not determine project type" warning is now reserved for genuinely ambiguous cases; well-formed v1 projects migrate without it.