MCP 2026-07-28 has shipped. Here's what your migration actually looks like.

On July 28, the MCP 2026-07-28 specification shipped — the largest revision since Anthropic open-sourced the protocol in November 2024. The preview coverage from last week was necessarily speculative: we knew the RC locked in May, we could read the SEPs, but we did not have the final diff, the SDKs, the codemod tool, or any feedback from servers that had actually run through the migration. Three days post-ship, we now have all four — and the picture is clearer than it was.

The spec isn't just the RC with a stamp

The release candidate published May 21 was 95% of what shipped, but the final spec tightened several loose screws. The deprecation of Sampling, Roots, and Logging — SEP-2577 — now carries an explicit twelve-month minimum window rather than the softer language in earlier drafts. The formal deprecation policy (SEP-2596) went from "planned" to "locked": Active → Deprecated → Removed, with each transition requiring at least one spec cycle. No feature can leap from Deprecated to Removed in fewer than twelve months. For server maintainers who worried the RC was a rushed housecleaning, this is reheating — the window is real and enforced.

Authorization hardening also graduated from draft to final. RFC 9207 issuer validation (OAuth 2.0 Authorization Server Issuer Identification) is mandatory for any MCP server doing OAuth 2.1 / OIDC. Dynamic Client Registration (DCR) — the old way — is formally discouraged in favor of Client Instance Metadata Documents (CIMD), a static metadata model that avoids the DCR bootstrap round-trip. If you shipped an MCP server with OAuth before this spec, your authorization flow is likely using DCR. The twelve-month clock on that started July 28.

On the protocol wire, SEP-2567 removed the Mcp-Session-Id header entirely. Every request is now self-contained: protocol version, client identity, and capabilities arrive in _meta on every call. Two new headers — Mcp-Method and Mcp-Protocol-Version — enable header-based routing, which means an MCP server running behind a plain NGINX or ALB can route without any deep packet inspection. The spec's own blog calls this "the most highly-requested feature from developers eager to get reliability and scalability for their MCP servers."

The SDK landscape: four betas, one codemod

The SDK situation as of July 31 is more concrete than the RC period's "Tier 1 SDKs are expected to ship within the ten-week window." They shipped:

• TypeScript: Split into @modelcontextprotocol/server and @modelcontextprotocol/client as separate packages on npm, both at v2 beta. The codemod ships as a CLI: npx @modelcontextprotocol/codemod. It handles the .tool() → registerTool rename, error-type renames, and the old initialize path removal automatically.
• Python: pip install "mcp[cli]==2.0.0b1". The createMcpHandler entry point from @modelcontextprotocol/server serves 2026-07-28 per request while also handling 2025-11-25 traffic from the same endpoint — the adapter packages connect it to Node.js, Express, Hono, and Fastify.
• Go: Same module path, pre-release tag — go get github.com/modelcontextprotocol/go-sdk@v1.7.0-pre.1.
• C#: dotnet add package ModelContextProtocol --prerelease

The critical detail in the migration docs is that v2 packages and the 2026-07-28 protocol revision are two separate steps. You can install v2 SDKs and continue speaking 2025-11-25 wire protocol while you become. Conversely, you can enable the new protocol revision on v2 SDKs when ready. This decoupling — SDK version ≠ wire protocol version — is not how most API ecosystems work, and MCP's choice to separate the two axes was deliberate: it lets teams upgrade dependencies without immediately breaking wire compatibility.

The TypeScript codemod covers the entire surface area of v1-to-v2 API changes: .tool() → registerTool, the error-type renames, and the initial removal from client bootstrap code. It does not handle the architectural shifts — removing session-store code, adding _meta forwarding, or replacing tasks/list pagination — but those aren't mechanical anyway. The codemod reduces a three-afternoon migration to one afternoon plus one architectural refactor.

What breaks now vs. what breaks later

The preview coverage lumped all changes together, but the shipping reality separates them into three categories:

• Immediately gone: initialize / initialized handshake (SEP-2575) and tasks/list. If your server exports these, new clients speaking 2026-07-28 will get errors. Older clients still negotiate version and will get the old behavior, but new ones won't.
• Deprecated with a 12-month clock: Sampling, Roots, Logging (SEP-2577). Still works, still spec-compliant, but the clock is ticking.
• New-but-optional: Multi Round-Trip Requests, header-based routing, cacheable list results, the formal extensions framework (Tasks as an extension, and MCP Apps), EMA as a hardened authorization surface. None of these are required — your server can serve the new spec without implementing any of them.

The most expensive migration for most server maintainers is not the codemod — it is removing session state. SE-2567 kills Mcp-Session-Id and the implicit state it assumed. Any server that used Redis, Memcached, or an in-memory dict to track sessions per connected client needs to re-architect around per-request state in _meta. The Glama MCP gateway maintainer, in an HN comment that surfaced after the ship, pegged state-management bugs as their #1 operational pain point — which explains why they pushed hardest to get this change through the RC.

Anthropic's take: "rolling out across Claude products"

Anthropic published its own post on July 28 confirming that 2026-07-28 support is "rolling out across Claude products soon," with the stateless core, standardized extensions, and hardened auth as the headline shipment. Claude Code, the Claude desktop experience, and the API's MCP surface all received updates that same week, including Cleanup's MCP servers need authentication startup notice being over-counting claude.ai connectors. The full product-level readiness is still mid-rollout, but the direction across the Claude lineup is alignment on this spec.

The practical consequence: if you're an MCP server maintainer whose primary users come through Claude tools, the window for supporting 2026-07-28 on your end is effectively now. Clients will start probing server/discover and expecting _meta on every request — and if your server only speaks 2025-11-25, those requests won't work once Claude flips to the new spec for default endpoints.

The concrete order of operations

If you haven't touched your MCP server since the RC, here is the order I'd follow now that the tooling is real:

1. Run the codemod. For TypeScript servers, npx @modelcontextprotocol/codemod gets the mechanical renames out of the way — .tool() to registerTool, error renames, init removal. For Python, the v2 beta package does the same import-path migration.
2. Remove the initialize handshake. In client code, replace any initialize call with server/discover. In server code, stop requiring sessions first. The protocol version must now arrive in _meta on every request.
3. Key session dependencies. Search for Mcp-Session-Id, any session-store initialization (Redis, Memcached, dict), and any code path that assumes a per-connection object lives across requests. Those code paths are now dead — even if your server still speaks 2025-11-25, the writing on the wall says this architecture is gone in twelve months, and v2 clients already skip the session.
4. Audit OAuth. If you do OAuth, check whether you're using DCR (old) or CIMED (new). DCR works for now with a twelve-month clock. The mandatory OIDC issuer validation (RFC 9207) means whatever target you direct users to for OAuth now has to validate across the new path.
5. Remove tasks/list if you used the old Tasks API (the pre-2025-11-25 experimental one). That endpoint went from clamped to removed. The replacement is task handles in the Tasks extension, with a handle-based polling model.
6. If you use Sampling, Roots, or Logging: start planning their removal now. They work until mid-2027, but you don't want to hit month eleven and scramble. The new Tasks extension absorbs most of what Sampling did; the Roots/Logging replacements are still emerging.

The migration is not trivial. But it's also not the breaking-change fire the preview coverage sometimes made it sound like. The codemod plus the 12-month removal window means you have time. The right move now is to upgrade in a branch, run the codemod, and avoid new dependencies on anything deprecated. The window is wide enough that no server needs to go down for this — but the servers that wait until month eleven will have the same amount of work without the same amount of time.

Everything the lab builds in public stays in public. The source is on GitHub, and the current build is a live AI quoting engine for home service contractors.