Model Context Protocol shipped with a handshake. You called initialize, the server answered, you sent initialized, and from then on a Mcp-Session-Id header tied your client to one server instance for the life of the conversation. It was the obvious design — sessions are how protocols have held context since the dawn of the cookie. The 2026 release candidate, locked on May 21 and final on July 28, takes all of it out.

That is the headline, and it is worth saying plainly because the maintainers do: this is a breaking change, "the kind of foundational change that needed a clean break." MCP is now stateless at the protocol layer. The non-obvious part is what the break admits — that the features that made MCP feel like more than remote function-calling are the same ones that didn't survive contact with production.

What stateless actually means

Six Specification Enhancement Proposals do the work, and they are best read as a single move. SEP-2575 deletes the initialize/initialized handshake and replaces it with _meta fields carried on every request. SEP-2567 removes the Mcp-Session-Id header and protocol-level sessions outright. The consequence, in the RC's own words: "any MCP request can land on any server instance, and the sticky routing and shared session stores that horizontal deployments needed before are no longer required at the protocol layer."

The rest of the cluster cleans up the corners that statelessness exposes. SEP-2260 says a server may only initiate requests during an active client request, not whenever it likes. SEP-2322 retires SSE streams in favor of Multi-Round-Trip requests that return an InputRequiredResult payload — the same elicitation pattern, without a long-lived connection to pin you to one box. SEP-2243 mandates Mcp-Method and Mcp-Name headers so a load balancer can route without cracking open the request body. SEP-2549 adds ttlMs and cacheScope to list and resource responses so clients can cache instead of re-fetch.

If you have ever tried to put an MCP server behind more than one replica, you already know why. The 2026 roadmap is blunt about the motivation: "stateful sessions fight with load balancers, horizontal scaling requires workarounds." The fix is to let servers "scale horizontally without having to hold state." This is the same operational pressure that pushed transport from stdio toward streamable HTTP — now followed to its logical end. A round-robin balancer and nothing else.

The deprecations are the tell

SEP-2577 deprecates three things, and the list reads like a confession. Roots — the mechanism for a client to tell a server which directories or URLs it may touch — gives way to ordinary tool parameters, resource URIs, or server configuration. Logging moves to stderr for stdio and OpenTelemetry for everything structured. And Sampling — the primitive that let a server ask the client's model to generate a completion — is deprecated in favor of servers calling an LLM provider's API directly.

That last one matters more than its bullet point suggests. Sampling was the feature that made MCP feel bidirectional, almost agentic: a server could borrow your model. We wrote about choosing between sampling and elicitation as a live design decision. The RC quietly settles it — elicitation survives as multi-round-trip requests; sampling does not. The deprecated features stay functional through the first spec year, so nothing breaks on July 29, but the direction is set.

MCP is converging on what actually shipped: stateless HTTP tool endpoints with serious governance. The clever bidirectional bits are being filed under "call the API yourself."

MCP Apps, and the part nobody will read

The additive news is MCP Apps: servers can now ship "server-rendered user interfaces" as interactive HTML that the host renders in a sandboxed iframe. Tools declare their UI templates ahead of time so the host can prefetch and security-review them, and — the line that matters — every UI action "go[es] through the same audit and consent path as a direct tool call." It is the same convergence visible in OpenAI's Apps SDK: the protocol war over agent UI is becoming a protocol agreement about sandboxing and consent.

Tasks, shipped experimentally in 2025-11-25, moves out of the core spec and into an extension, redesigned around the stateless model — servers answer tools/call with a task handle, clients drive it with tasks/get, tasks/update, and tasks/cancel.

But the durable change is governance, and it is the part most teams will skip. Three SEPs install the machinery to never do another clean break: a feature lifecycle (SEP-2596) with Active → Deprecated → Removed phases and "at least twelve months between deprecation and the earliest possible removal"; an extensions framework (SEP-2133) where opt-in features use reverse-DNS IDs, negotiate via capability maps, and version independently; and a conformance requirement (SEP-2484) under which no Standards-Track SEP reaches Final until a matching scenario lands in the conformance suite. Pair that with the roadmap's planned .well-known metadata format — so the registry can describe a server's capabilities without a live connection — and you can see the shape of the thing it wants to be.

What to do before July 28

If you maintain a server, the migration is real but mechanical: stop relying on session IDs, move per-connection state into _meta or external storage keyed by the request, replace SSE with multi-round-trip, and drop sampling calls in favor of your own model client. If you build servers for a living, the better question is the one the deprecations pose: how much of your design leaned on MCP being stateful and bidirectional? The protocol just bet that the answer should be "as little as possible." Behind a round-robin balancer, with a twelve-month clock on everything it removes, that bet looks less like a retreat and more like the version that scales.