Blog / · 6 min read
MCP is getting a new skeleton: what the 2026 protocol overhaul will break for you
Sessions removed, state moved into handles, auth aligned with OAuth. If you already have MCP servers in production, this RC is not a minor version bump. Here's what's actually changing.
Okay. If you already have one or more MCP servers running in production, I’ve got bad news and good news.
The bad news: the protocol you built on is changing its foundations. Not a patch, a real refactor.
The good news: a good chunk of this refactor is exactly the kind of technical debt everyone was complaining about having to manage themselves — sticky routing, dragging sessions between instances, that whole annoying pile of stuff. The protocol now handles it for you.
I want to be clear about one thing right away: today is July 12, 2026. The final spec of this revision is scheduled for July 28. So as I’m writing this, it’s a release candidate, not a locked-in text. I’ll stay honest about that status throughout, because I find it a bit wild watching people react to RCs as if they were already carved in stone.
The real change: MCP becomes stateless at the protocol level
Until now, an MCP client would do an initialize/initialized handshake, get back an Mcp-Session-Id, and then had to consistently route to the same server instance to keep its context. If you’ve deployed multiple instances behind a load balancer, you know the pain: sticky routing, shared session stores, the whole usual folklore of stateful apps.
The RC flat-out removes this mechanism at the protocol level. No more initialization handshake, no more session header. Every request becomes self-sufficient, with its metadata embedded directly inside it.
Concretely: “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.” Translation: your load balancer can go back to being a dumb round-robin, no more need for session affinity, no more need to deeply inspect traffic to route — you can even route on a simple Mcp-Method header.
If your server needed state, you now have to migrate to an explicit handle pattern: the server generates an identifier (a basket_id, a browser_id, whatever name you want) and the model passes it back as an ordinary argument on subsequent calls. Basically what HTTP APIs have always done. State becomes visible to the model again, instead of hidden inside an invisible server-side session.
This is where the real migration work sits if you have an MCP server relying on implicit sessions today. If your server keeps in-memory state attached to a session, you’ll have to rewrite it to expose that state through an explicit handle. It’s not dramatic, but it’s not a simple version bump in your package.json either.
What gets easier to operate
I won’t pretend I’m against this. Honestly, for anyone who’s already struggled scaling a stateful MCP server across multiple pods, this part of the refactor is good news. No longer depending on a shared session store, no longer needing sticky routing — that seriously simplifies observability and horizontal scaling. You can treat an MCP server like any other stateless HTTP service: any instance can answer, you scale with plain replicas, your monitoring goes back to being standard.
It’s the kind of change that, on paper, sounds like an architectural detail. On the ground, it means fewer incidents where “this request landed on the wrong instance and lost its context.”
The extensions: Tasks breaks, MCP Apps opens a new surface
Two extensions ship officially with this revision.
Tasks, first. If you’d already wired up the experimental tasks API from the 2025-11-25 revision, brace yourself: it’s a breaking change. The new lifecycle requires the client to drive it with tasks/get, tasks/update, and tasks/cancel. So if you coded against the old experimental API, you’ll need to migrate.
MCP Apps, next. This is the one I find most interesting, and also the one that worries me a bit. It lets a server return server-rendered HTML interfaces, which the client displays inside a sandboxed iframe. In plain terms: your MCP server can now push UI, not just data or tool calls.
That’s convenient. But it shifts the risk surface. An MCP server that used to return text or JSON, you can audit relatively easily. A server that returns HTML rendered inside an iframe, even sandboxed, is a whole new class of review you need to add to your security checklist — whether for your own server or for the third-party ones you connect to. If you work with MCP servers you don’t control, this point clearly deserves a spot on your watchlist before you enable the extension.
Auth: stricter, but more standard
Six proposals align MCP authorization with OAuth 2.0 and OpenID Connect practices: validating the iss parameter per RFC 9207, declaring application_type in Dynamic Client Registration, and binding credentials to the issuing authority. Nothing revolutionary if you’ve already worked with serious OAuth elsewhere, but if your current implementation is a bit homemade on this front, you’ll need to beef it up to stay compliant.
Three things heading to deprecation, no rush
Roots, Sampling, and Logging enter formal deprecation. Roots gets replaced by tool parameters, resource URIs, or server config. Sampling by direct integration with the LLM provider’s API. Logging by stderr in stdio, or OpenTelemetry for structured observability.
Good news: the deprecation policy requires a minimum of twelve months between the announcement and actual removal. In this revision, these are “annotation-only” deprecations — so nothing breaks today. But if you use these three features, now’s the time to plan the migration instead of getting caught off guard a year from now.
What I’d actually do
Since we’re still on an RC and the final text is expected on July 28, I wouldn’t rush to rewrite everything this week. The ten-week window between the RC lock (May 21) and the final release exists precisely so SDK maintainers and implementers can validate against real workloads — so the official SDKs should absorb a good chunk of the migration complexity.
What I’d actively watch: does my server depend on implicit sessions (migration to handles to plan for), was I using the experimental Tasks API (confirmed breaking change), and am I planning to enable MCP Apps at some point (new surface to audit, not to enable by default without thinking it through).
And above all: I’d check the final text on July 28 before migrating anything to production. An RC can still move. I already dug into the MCP server ecosystem in MCP servers, the real surprise of 2026, and the same rule applies here: it’s a protocol that’s maturing fast, but still maturing.
Sources
Keep reading