What Does the New Stateless MCP Specification Actually Change?

What changed in the July 2026 MCP specification?

As of September 2026, the current Model Context Protocol revision is 2026-07-28. Its headline change is that MCP moves from a bidirectional stateful protocol to a request and response stateless one. The maintainers describe it as the most substantial set of changes since authorization was added.

That sentence sounds like plumbing, and in one sense it is. But it decides where MCP servers can run, what they cost to operate, and how hard they are to secure. Those three things matter to anyone putting AI tooling anywhere near production.

We have been reading the revision closely because it changes advice we were giving six months ago. Here is what actually shifted, and what we think teams should do about it.

Why does going stateless matter so much?

Because a stateless server is a normal web service, and a stateful one is not. The new revision removes the initialize and initialized exchange and drops session identifiers. A request now carries what it needs, so any instance can answer it.

Under the old model, a client opened a connection, negotiated, and then kept that session alive. That works on one machine. It gets awkward the moment you want two machines behind a load balancer, because the second one does not know about the session the first one holds.

Stateless removes that whole class of problem. You can run MCP servers on ordinary autoscaling infrastructure, behind a standard load balancer, with no sticky sessions and nothing to keep warm. For teams who deploy everything else that way, this is the change that makes MCP boring in the best sense.

If it is stateless, how does a server call the client?

Through Multi Round-Trip Requests, which the revision introduces for exactly this. MRTR lets a server make requests back to a client without needing a continuously open bidirectional stream. The capability survives, the permanent connection does not.

This matters because plenty of useful tool calls need something from the user partway through. A server might need to ask for permission, request a missing value, or hand back a choice. Under the old design that required the stream to stay open the whole time.

The practical effect is that you keep interactive behaviour without paying for an idle connection per user. For anything running on a serverless platform, where an open connection is the expensive part, this is the difference between viable and not.

Why move method names into HTTP headers?

So that infrastructure can make decisions without reading the message body. In the new revision, method and tool names travel in the Mcp-Method and Mcp-Name HTTP headers. A gateway can route and authorise on those headers directly.

Think about what that enables. Your API gateway can allow one tool and block another without parsing JSON. Your rate limiter can treat an expensive tool differently from a cheap one. Your logs can show which tool was called without recording the payload, which is a real privacy win.

This is the change we expect enterprise security teams to like most, because it lets existing controls apply to MCP traffic. Nobody has to build a bespoke inspection layer to answer the question of which tool an agent just tried to use.

What changed about caching and authorization?

Two separate hardening moves. List results are now cacheable, with cache hints and deterministic ordering so upstream caches behave predictably. On the authorization side, the revision adds RFC 9207 issuer validation and shifts away from Dynamic Client Registration toward Client ID Metadata Documents.

The caching part sounds minor and is not. Listing available tools is one of the most repeated calls in any MCP deployment, and it rarely changes between calls. Making that cacheable with stable ordering cuts a lot of pointless work, which shows up directly in cost.

The authorization change is about trust. Issuer validation closes a class of confusion where a token from one issuer could be accepted by the wrong party. Moving toward metadata documents gives a more predictable way to identify clients than registering them dynamically. Both are the sort of change you only notice when they are missing.

What is the extensions framework for?

It gives optional capabilities a formal home instead of leaving them as vendor additions. The revision establishes extensions including Tasks, MCP Apps, and Enterprise Managed Authorization. These sit alongside the core rather than inside it.

The reason this is healthy is that it keeps the core small. A protocol that absorbs every good idea becomes impossible to implement fully, and then implementations quietly diverge. Extensions let ambitious features exist without every client being obliged to support them.

For a team choosing tools, the thing to check is which extensions a given server or client actually implements. Supporting MCP no longer tells you very much on its own, in the same way that supporting HTTP does not tell you which methods a server handles.

Will this break the MCP servers you already run?

Some of them, yes. The maintainers are clear that the revision includes changes that are not backward compatible, particularly around session identifiers. A server built for the new revision may not work with an older client, and the reverse is also true.

There is a cushion. The revision commits to a twelve month minimum window for anything formally marked deprecated, which the maintainers frame as time to plan upgrades rather than react to them. That is a reasonable runway for a small team.

So this is not an emergency, but it is a dated task. If you run MCP servers in production, the useful move this quarter is to find out which revision each one targets and write down the answer somewhere your team will look again.

Is this ecosystem big enough to bet on?

The download numbers suggest it is past the experiment stage. The maintainers report close to half a billion downloads a month across the Tier 1 SDKs, with the TypeScript and Python SDKs each crossing one billion total downloads. The Tier 1 set now covers TypeScript, Python, Go, and C sharp.

Download counts are a rough measure and they include continuous integration runs, so read them as scale rather than as users. Even discounted heavily, that is a lot of installs, and four officially supported languages covers most of the stacks our clients actually build on.

The more meaningful signal is the shape of the changes themselves. Statelessness, header routing, and cache hints are the concerns of people running things at scale, not people prototyping. Our piece on MCP servers for web teams covers what these servers do day to day.

Should a small marketing team care about any of this?

Only in one way, but it is a useful one. You do not need to read the specification. You do need to ask your vendors which revision they support, because the answer tells you whether their integration will still work next year.

The second thing worth knowing is that stateless servers are cheaper to run. If a vendor is charging you a premium that they justify with infrastructure cost, that justification is weaker than it was in July. That is a fair question to raise at renewal.

Beyond that, this is a plumbing upgrade and plumbing upgrades are good news when they are boring. Our notes on evaluating AI automation for production cover the questions we would ask a vendor before depending on one.

How would we approach the upgrade?

Inventory first, then the riskiest server, then the rest. Write down every MCP server you run or depend on, which revision it targets, and who owns it. That list usually surprises people, because a couple of them turn out to have no owner at all.

Then upgrade the one with the most access, not the one that is easiest. The server that can write to your CMS or your CRM is the one where the authorization hardening actually earns its keep. Test it against a client on the new revision before you move anything else.

Do not upgrade everything at once, and do not let the twelve month window lull you into starting in month eleven. Two servers a month is a calm pace that finishes comfortably. Our guide to human in the loop workflows covers where to keep a person in the path while you are changing the plumbing underneath.

Where is this heading?

Toward MCP being infrastructure rather than a novelty. Every change in this revision points the same way, which is making agent tooling look like ordinary web services that ordinary operations teams can run. That is what adoption at real scale requires.

Our expectation, and it is an expectation rather than a plan we have seen published, is that the interesting work moves into extensions from here while the core stays still. A stable core is what lets everyone else build with confidence.

If you are working out what the new revision means for the AI tooling around your site, or you want help auditing what you already run, we are happy to walk through it. You can find us at phoenix.studio.