Building an MCP server on your laptop has become relatively easy. Running one for 10,000 employees has not.
That gap is driving a significant portion of the new MCP release. The headline is a rework of the core protocol from stateful to stateless, with session IDs going away.
If you’ve only run MCP servers locally, this might sound like irrelevant plumbing. But if you build or operate servers and gateways at scale, the breaking change in this release will force a rewrite in the short term and provide a lot of benefit in the long term.
Let’s walk through what’s changing and why.
Where stateful sessions came from
Early on, Model Context Protocol grew from the assumption that servers would be local. MCP’s early design was inspired by the Language Server Protocol that powers code editors like Sublime and VSCode, which also run locally. On your local machine, having two processes talk to each other statefully is no big deal.
Here’s what it looks like in MCP today (or, yesterday):
The first time an MCP client like Claude connects to a server, it sends a “hello”: I’m Claude, here’s my version, here are my capabilities. The server replies with its own capabilities and hands back a session ID. In MCP, this handshake is called initialize.
From then on, the client sends that session ID on every request so the server knows it’s the same conversation. Sometimes the ID expires, so the client has to notice, request a new one, and carry on.
On one machine, that’s trivial. Store the session ID in memory and you’re done. At enterprise scale, it becomes a problem.
Why stateful sessions break at scale
Picture a real deployment. You’re running a server for millions of users, behind a load balancer whose entire job is to route each request to whatever server in the farm is free, sometimes in a different region. Now every one of those machines has to know about a session ID that some other machine handed out. It’s not impossible, but it’s a serious pain, and it fights the load balancer instead of working with it.
The web solved this long ago. A long time ago, you configured “sticky sessions,” pinning a browser to the one server that held its state. But as the web grew, we preferred stateless applications, where the server itself doesn’t have to remember you between requests. That’s the pattern MCP is finally adopting.
This scale problem is one reason why first-party MCP servers have been slow to arrive. They exist, but not everywhere! Plenty of big companies can stand up a demo. Getting to full production and serving millions of users runs straight into the session problem and frequently stalls there.
What stateless actually means
“Stateless” is easy to misread, so let’s be precise!
It does not mean there’s no state, and it doesn’t mean that MCP is now limited to simple requests. It means the server doesn’t have to remember anything between requests, because the client sends everything the server needs every time.
In practice, that opening handshake I mentioned before disappears. The client no longer says hello and negotiates a session up front. Instead, it sends a request, and everything important now travels on each request instead. In practice, that’s just a few extra fields and headers. Instead of identifying itself once, the client identifies itself on every call the same way a browser sends a user-agent header.
The short version is that MCP is starting to behave the way the web already has for decades. That’s good!
Why it’s a hard break
In protocol terms, this is a breaking change. A client built for version 2025-11-25 expects to initialize and carry a session ID, so it can’t talk to a server expecting 2026-07-28. The reverse is true, too.
MCP already has an escape hatch, though: version negotiation. A client can declare that it only speaks the 2025-11-25 protocol, and a server that’s capable of speaking either can speak to that client but still support newer clients using today’s protocol. This means the ecosystem doesn’t fall apart (good!), but supporting multiple versions at once takes real work and is difficult to sustain.
For a server or client developer, this is a significant rewrite. The new protocol is actually simpler to implement, with far less tracking of where you are in the conversation, but there’s just no getting around that it will be new work for anyone who’s already written all the stateful code.
The payoff is scale and stability
The short-term pain buys a real long-term gain, and it comes back to scale.
Deleting session handling makes it far easier to build and maintain high-quality servers at scale, which is exactly what has held back official first-party servers from the companies best positioned to run them. My hope is that this release finally gets more of them to plant a flag: this is the official, supported way for agents to reach our service.
As users, we all get a second benefit, which is stability.
A lot of the sharp edges with MCP today trace back to how brittle session handling is. At Arcade.dev, we routinely file bug reports on clients that mishandle expired sessions and on connections that die and won’t come back. Delete that code and a whole class of bugs goes away with it.
The MCP team has already done great work here, getting the official SDKs compliant and building out the official conformance suite that tells you whether you’re speaking the protocol correctly. Once everyone clears the rebuild, the ecosystem should land somewhere far more stable.
What this means if you build servers or agents
Short term, expect fragmentation.
Any breaking change to an ecosystem this size opens a window where some clients have auto-updated to the new protocol and some servers haven’t, and vice versa. Maybe your clients and servers line up. Maybe they don’t. If you operate an agent fleet, or roll agents out to a workforce, the last thing you want is a version-compatibility matrix where version 1.5 works, version 1.7 doesn’t, and you’re the one debugging why at 2 a.m.
Where Arcade.dev fits in
This is where a gateway shines!
Arcade sits between your clients and your servers as an MCP gateway, and we’ve already implemented both the previous protocol version and the new stateless one. A client that hasn’t upgraded connects through us and still works. An upgraded client shows up, and we’ll also speak the new protocol regardless of whether all your servers do. The rough edges of the transition get handled in one place you control, instead of across every server-client pair you operate.
There’s also a deeper reason the runtime layer matters here. With Arcade, the parts you can’t afford to fragment (authorization, security policy enforcement, and governance) don’t live in the protocol at all. They run in the runtime, on every action, no matter the protocol version a given client speaks. A stateless rewrite churns the transport underneath, but your important controls hold steady.
This is exactly the kind of ecosystem-wide transition we built Arcade for. The fragmentation is temporary, and the ecosystem will settle again. In the meantime, the enterprises actually deploying agents don’t have time to babysit a compatibility matrix, and they shouldn’t have to.
MCP is growing up. The protocol won’t absorb the transition costs for you. Something in your stack has to, and that’s the job we signed up for.
