MCP dropped state. What that means if you run the servers

What happened on 28 July

The Model Context Protocol — the standard through which language models reach tools and data outside themselves — received its biggest spec revision since launch on 28 July 2026. The core of the protocol moved from a bidirectional, stateful model to a stateless, request/response core. Alongside that, the revision added multi-round-trip requests, routing by the Mcp-Method header, cacheable tool-list results (tools/list), tighter authorization, a formal extension framework, and an updated first tier of official SDKs.

In plainer terms: previously a client and a server held a live, ongoing connection between them, where order mattered and so did what had happened earlier. Now each request is meant to stand on its own as far as possible — it arrives, it gets an answer, and that is the end of it. It sounds like a detail two people on Earth care about. Yet according to the developer community this was one of the most requested changes of all, for two reasons any operator hears loud and clear: reliability and scalability.

Why those two hurt the most is easiest to see by looking at what a "stateful" protocol actually cost the person keeping the server running.

What "stateful" really cost the operator

When a server has to remember, between requests, who you are and where you left off in a conversation, it stops being irrelevant which instance the network routes you to. Your second request has to land on the same machine as your first — otherwise it hits a server that knows nothing about you. That is called sticky sessions, and it is the first in a chain of complications that statefulness drags behind it:

• Sticky sessions on the load balancer. The balancer cannot scatter one client's requests randomly across instances; it has to keep them together. That narrows how you can spread load, and it complicates every deploy where instances get swapped out.
• A shared session store. So that a session survives one instance crashing or being restarted during a deploy, the state is typically kept in a shared store. That is another component to run, back up and watch — and another place where consistency can go wrong.
• A smarter gateway. For the gateway to know how to route a request correctly, it often had to look deeper into the body, not just the headers. More logic on the gateway means more things that can break there.

Each of those three is manageable on its own. Together they form what operations people call "moving parts" — and there is a simple law: the more moving parts, the more things that break at 3 a.m. Scaling a stateful service is not impossible, it is just more expensive in attention. And attention is the scarcest currency in operations.

What stateless changes

When every request stands on its own, that whole structure collapses — in a good way. The Register, covering the revision, put it exactly: a server that used to need sticky sessions, a shared session store and deep packet inspection at the gateway can now run behind a plain round-robin load balancer, route on the Mcp-Method header, and let clients cache the tool list on their side.

Take it apart, because each piece removes one moving part:

• A plain load balancer. When it does not matter which instance a request lands on, you just rotate through them. Sticky sessions disappear, and with them a whole class of problems around deploys and single-instance failure.
• Header-based routing. The gateway decides on Mcp-Method in the header, not on parsing the whole request body. That is cheaper, more transparent and more reliable — even a dumb gateway can read a header.
• A cacheable tool list. The set of tools a server offers does not change on every call. When a client is allowed to cache it, the repeated round-trips where the server answers the same thing every time drop away. Less pointless work on both ends.

The summary is as boring as the whole revision: fewer moving parts means fewer things that break. The shared session store that existed only for sessions can, for part of a deployment, fall away entirely. This is not a new feature you could put on a billboard. It is subtracted complexity — and subtracted complexity is exactly what an operator most likes to pay for.

A migration checklist, in general terms

Here I have to be honest about what I am writing about and what I am not. I am not describing how my own servers are built — I keep that to myself. I am describing what anyone running an existing MCP server today should look at when weighing a move to the stateless core. The points below hold generally, wherever the thing runs:

• Find where you rely on state. The first question is not technical but an inventory: what does your server remember between requests today? Conversation progress, an authenticated session, a half-finished multi-step operation? Every such spot is a candidate for a rewrite — either the state goes away, or it has to travel in every request.
• Expect the shared session store may leave. If it existed only for sticky sessions, statelessness removes its reason to be. That is a saving, but also a migration: before you switch it off, be sure nothing else is hanging on it.
• Walk through authorization, because it got stricter. The revision tightened authorization, it did not loosen it. That is work added, not removed: confirm that every request authorizes on its own once it can no longer lean on the context of an earlier session. This is where I would rush least and read the spec most carefully — authorization is where a mistake costs security, not latency.
• Turn on tool-list caching deliberately. A cacheable tools/list saves work, but it means clients may see an older tool list for a while. If your tool offering changes, you need to think through how stale the list may be — otherwise a client calls a tool you have already pulled.
• Verify multi-round-trip requests. Stateless does not mean every operation is a single lone request. The revision explicitly allows multi-round-trip exchanges; it just has to be clear from each request which operation it belongs to, without leaning on shared state.

None of those is rocket science. Together, though, they are exactly the spots where a quiet "it'll run somehow" migration ends up at a request landing on an instance with no context — and failing in a way a single-instance test never surfaces.

The wider context: MCP grew up

This revision only makes sense in the light of where MCP moved over the past year. From a tool that was mostly useful for wiring a model to a few scripts on one machine, it became a distributed protocol — and a distributed protocol has entirely different worries. Sticky sessions bother no one while a single instance runs on one laptop. They start hurting precisely when a service runs across several instances behind a gateway and has to survive a deploy without downtime. So the revision is an answer to maturity, not to fashion.

The maturity shows in numbers that are hard to miss. The first tier of official SDKs pulls on the order of half a billion downloads a month; the TypeScript and Python libraries have each passed a billion downloads in total. By mid-2026, per the available overviews, the protocol had been adopted by OpenAI, Google DeepMind, Microsoft and AWS, and by hundreds of enterprise vendors. This is no longer a hobbyist's toy.

And above all: the protocol moved to neutral governance. It is now stewarded by the Agentic AI Foundation, a fund under the Linux Foundation, whose platinum members include — alongside Anthropic — OpenAI, Block, Google and Microsoft. For anyone building on the standard, this matters more than any single feature. It means the protocol is not the property of one company that a single strategic pivot could push into changing the rules from under you. The stability of a standard is a value in itself — and for an operator, perhaps the most valuable one.

What I take from it

This change is boring, and that is the best thing about it. It adds no feature I could show anyone on a screen. It subtracts complexity nobody sees until it breaks. It takes a protocol that started as a clever local wiring and turns it into infrastructure that behaves like any other well-designed network service: request in, response out, no hidden memory in between.

For someone who runs the servers, this is exactly the kind of news you like — because it does not sound excited. Excited news, in operations, usually means something broke, or that someone added a feature you will spend two years babysitting. This news says the opposite: there will be fewer things to babysit. Fewer moving parts, fewer 3 a.m. wake-ups, a simpler path from one instance to a hundred.

If anyone outside the narrow circle of operators should take one thing away, it is this: the standard on which agentic tools are being built just stepped from "clever but fragile" to "boring but solid". And when I am choosing what to build something on that has to run for years, I take boring and solid every time.

---

Sources: the revision announcement on the Model Context Protocol blog (28 Jul 2026) and The Register's coverage (29 Jul 2026). The operational reasoning here is general — it describes what the revision changes for MCP operators at large, not any specific deployment.

Weighing how to fold agentic tools and MCP into your own operations? → AI consulting