The MCP 2026-07-28 specification shipped two days ago, and it is the largest protocol rewrite since MCP launched. Sessions are gone. The initialize
handshake is gone. Five core features are deprecated. Anthropic’s own spec lead put it plainly: “a lot of things that made MCP are gone.” If you maintain an MCP server or client, this is not a skim-later situation.
Why MCP Was Stateful in the First Place #
MCP started as a way for coding tools to run locally. That origin shaped the protocol: a bidirectional stateful connection made sense when the server and client lived on the same machine. Craig McLuckie, CEO of Stacklok, explained it well: “The stateful nature of MCP was really a by-product of its origin as a way to support developers using coding tools that tend to run locally.”
That worked fine in 2024. By mid-2026, MCP SDKs are crossing a billion downloads. Teams are deploying MCP servers behind load balancers, across regions, with real auth requirements. A protocol that needs sticky sessions and shared session stores is a scaling problem. The 2026-07-28 spec fixes this — at the cost of breaking backward compatibility for anyone building with stateful assumptions.
The Core Breaking Change: Sessions Are Dead #
The mandatory initialize
/initialized
handshake is removed. Mcp-Session-Id
headers are gone. Every request is now self-describing: protocol version, client identity, and capabilities travel in a _meta
object inside the JSON-RPC envelope. Clients that want to negotiate capabilities upfront can call the new server/discover
endpoint — but it is optional, not mandatory.
The practical upside is significant. A remote MCP server that previously required sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer. Standard HTTP scaling patterns apply. This is MCP growing up from a local dev tool into a production protocol.
The migration cost is also real. Any server that stores per-session state between calls breaks. That state has to move to an external store and be passed explicitly. David Soria Parra, who leads the spec at Anthropic, was direct: “it’s going to be a lot of uplift to make this correct” for custom implementations.
Five Features Deprecated — Audit Your Code Now #
Five features enter formal deprecation with a 12-month window. Removal is earliest July 28, 2027, giving teams time — but not infinite time. Check whether your implementation relies on any of these:
Roots— the client mechanism for advertising filesystem boundaries. Replace with explicit directory paths passed as tool parameters or server configuration.Sampling— the server mechanism for requesting model completions from the client. Migrate to direct LLM provider API calls.** Logging**— protocol-level logging notifications. Switch to stderr, stdio, or OpenTelemetry.** Dynamic Client Registration (DCR)— replaced by Client ID Metadata Documents (CIMD). HTTP+SSE transport**— already functionally dead. Now officially deprecated.
None of these are catastrophic migrations, but they require deliberate planning. Teams building on deprecated foundations today are scheduling debt for next year.
What the New Spec Adds #
The 2026-07-28 spec is not only subtractive. Two additions stand out for developers building real-world agents.
Multi Round-Trip Requests (MRTR) solve a long-standing annoyance. Previously, getting mid-call user confirmation required keeping a connection open — or working around it with Sampling, which is now deprecated. MRTR lets tools return an InputRequiredResult
, , and resume when the user responds. No persistent connection required. This enables approval gates in agentic workflows without architectural gymnastics.
Header-based routing is the ops win. Mcp-Method
and Mcp-Name
HTTP headers carry routing information at the network layer. Gateways and load balancers can make routing and authorization decisions without parsing JSON bodies. CDN-level caching and edge security policies become possible. tools/list
responses now include ttlMs
and cacheScope
fields so clients can cache tool manifests intelligently.
Authentication: CIMD and OAuth 2.1 Hardening #
The auth story tightens meaningfully. Dynamic Client Registration is out; Client ID Metadata Documents (CIMD) are in. Servers must now expose a .well-known/oauth-protected-resource
endpoint per RFC 9728, enabling automatic authorization server discovery. RFC 8707 Resource Indicators require clients to explicitly declare which server a token targets — eliminating cross-server token replay attacks by spec. RFC 9207 issuer validation is required.
The concrete security win: a token minted for Server A cannot be replayed against Server B. For teams running multi-server MCP deployments with sensitive data, this closes a real vulnerability class that existed in previous spec versions.
SDK Status and How to Start Migrating #
Beta SDKs targeting the 2026-07-28 spec are available now across all Tier 1 languages:
Python v2.0.0b1:FastMCP
is renamed toMCPServer
. Install withpip install "mcp[cli]==2.0.0b1"
. The decorator API is preserved.TypeScript v2 (beta): Split into@modelcontextprotocol/server
and@modelcontextprotocol/client
. ESM-only, Node.js 20+ required. A codemod is available to automate much of the migration.Go v1.7.0-pre.1 andC# v2.0.0-preview.1: Backward-compatible APIs with protocol adoption opt-in via configuration flags.
For server authors, the concrete migration checklist:
- Remove the
initialize
handshake — treat every incoming request as self-contained - Externalize session state to an external store; pass context explicitly via tool arguments
- Add support for
Mcp-Method
header routing - Include
ttlMs
intools/list
responses - Validate tool schemas against JSON Schema 2020-12
- Implement the RFC 9728
.well-known/oauth-protected-resource
endpoint - Audit usage of Roots, Sampling, and Logging and plan replacements
New projects should start on the 2026-07-28 spec and beta SDKs today. The stateless model is simpler to reason about and easier to scale. Existing projects should prioritize the session state migration first — everything else is manageable in phases. The 12-month deprecation window gives breathing room, but not much. Teams that wait for stable SDK releases before starting the audit are compressing an already tight timeline. The full specification and migration details are on the official MCP blog.