For a year, the most honest sentence in any MCP deployment guide was a warning: your remote server needs sticky sessions. The Model Context Protocol opened every connection with an initialize/initialized handshake, handed back an Mcp-Session-Id, and expected that header on every subsequent request. Which meant a load balancer couldn't just round-robin traffic. It had to pin each client to the instance that owned its session — or you had to stand up a shared session store and hope your gateway could read far enough into each request to route it. The protocol that was supposed to make integration boring made horizontal scaling hard.
The 2026-07-28 release candidate, locked on May 21, deletes that sentence. The handshake is gone. The session header is gone (SEP-2567). Client metadata that used to be negotiated once at connection time now rides in _meta on every request. The practical consequence is the one production teams have been asking for since the 2026 roadmap promised servers that scale "horizontally without having to hold state": any request can land on any instance. A remote server that previously needed sticky routing, a shared session store, and deep packet inspection at the edge can now sit behind a plain round-robin load balancer. If you've been weighing stdio vs SSE vs Streamable HTTP for a remote deployment, this is the change that finally makes the HTTP path behave like an ordinary stateless API.
"Stateless" doesn't mean "amnesiac"#
The word stateless scares people who have actual state to manage, so be precise about what moved. The protocol no longer carries a session for you. Your application can still carry one — exactly the way HTTP APIs have done since forever. A tool mints an explicit handle, a basket_id or a browser_id, returns it, and the model passes it back as an ordinary argument on the next call. State becomes data in the conversation instead of a hidden side-channel in the transport. That's not a downgrade; it's the same move REST made when it refused to remember you between requests and made you send a token instead.
The session didn't carry your application's state. It carried the protocol's, and the protocol decided it didn't want to.
This is the part worth internalizing before you migrate: removing the session is cheap for most servers precisely because most servers were already faking statelessness on top of a stateful protocol. The RC just stops charging you for the fiction.
The headline is statelessness. The story is the shrinking core.#
Read past the load-balancer win and a bigger pattern shows up in the changelog. Tasks — the primitive for long-running work — graduated out of the experimental core and into an extension. A server now answers tools/call with a task handle, and the client drives it with tasks/get, tasks/update, and tasks/cancel (tasks/list was cut). MCP Apps, the new server-rendered HTML surface, also arrives as an extension, with tools declaring their UI templates ahead of time so hosts can prefetch, cache, and security-review them before anything renders.
And on the other side of the ledger: Roots, Sampling, and Logging are deprecated, each with at least twelve months between deprecation and removal under a new lifecycle policy. The Sampling deprecation is the tell. Sampling let a server reach back through the client to make its own model calls — the most stateful, most awkward-to-secure capability in the whole protocol. Dropping it isn't housekeeping. It's a thesis.
The thesis is that the core of MCP should be a thin, stateless request/response kernel, and everything stateful, opinionated, or enterprise-specific should live in independently versioned extensions with reverse-DNS identifiers and their own track through the SEP process. The roadmap is blunt that enterprise needs — "audit trails, SSO-integrated auth, gateway behavior" — will "land as extensions rather than core spec changes." MCP is de-monolithizing. The protocol you target is shrinking; the ecosystem of extensions around it is where the growth goes.
That reframes the authorization work too. Six SEPs tighten alignment with OAuth 2.0 and OpenID Connect — iss validation, an application_type declaration during Dynamic Client Registration — not by inventing MCP-specific auth, but by deferring harder to the standards your identity team already runs. Same instinct: keep the core small, lean on infrastructure that already exists.
What to actually do before July 28#
The final spec ships July 28, 2026, and the ten-week window from the RC lock exists so SDK maintainers and Tier 1 clients can validate against real workloads — not so you can panic-rewrite in a weekend. Three concrete moves:
- Audit your session assumptions. Anywhere your server stashed state keyed on
Mcp-Session-Id, plan the explicit-handle replacement now. If a tool's behavior depends on "which connection asked," that logic needs a real argument. - Re-home your long-running tools onto the Tasks extension instead of holding a request open or inventing your own polling. The lifecycle is now standard; use it — and if those tools accumulate context across calls, the same context editing vs compaction tradeoffs apply.
- Watch the deprecation clock on Sampling. If any server reaches back for model calls, you have roughly a year, and the direction of travel says design it out, not around.
The 2026 spec will get sold as "MCP got faster to deploy," and it did. But the durable change is structural: a protocol that spent its first two years absorbing features just started giving them away. For once, the boring infrastructure decision and the interesting design decision are the same one.
