Nate Barbettini already walked through the big picture of the new Model Context Protocol (MCP) release, explaining that the core protocol is moving from stateful to stateless, and session IDs are going away. If you want the why, start with his overview.
This piece is for the people who have to do the work. I build Arcade.dev’s runtime, so I want to get specific about what changes when you run MCP servers or gateways in production, and what to check before the release lands.
The multi-user session store was the real tax
On a single client, a session ID is harmless. You connect, you get an ID, and you send it back on every request. From the perspective of a single user agent, this can be great for long-running and multistep operations. The cost shows up the moment more than one user is involved.
If you build an agent that handles multiple users, you have to keep a session for each of them, and map requests to the correct one. Then you try to scale the service, and it gets harder. A session is usually tied to the one server instance where the request was initialized, so once you run replicas, any replica that picks up a user’s next request needs that same session. At that point you are building a shared session store and wiring every replica into it or using sticky sessions, just to receive requests, even if your server doesn’t require state.
That is the hidden tax of statefulness, and the new stateless protocol removes it. The client sends everything the server needs on each request, so any replica can answer any request, and the session store goes away.
What actually breaks day one
For simple tool calls, the work gets easier. There is no initialization step anymore, so you just call the tool. That’s it. One whole step leaves your process.
The break shows up when your server logic depends on state. Long-running work used to lean on the session. You kicked something off, and the server pushed updates back to you. It’s convenient, but increases the complexity of your server. In the stateless model, you get a handle for that long-running work and poll it, asking the server whether it has finished, closer to how a REST call behaves. It is a familiar pattern, but it is a real change. The server no longer notifies you on its own, so that polling logic now lives on the client.
If you built long-running tools against sessions, budget time to migrate them before you upgrade.
Where Arcade fits in
Two things are worth knowing if you run through Arcade.
First, you do not have to upgrade everything at once. Arcade speaks the older versions that still use session IDs and the new stateless version at the same time, so you can move your servers and clients over on your own schedule instead of coordinating a single cutover.
Second, as the protocol grows with extensions and other new features, we’ve got your back. Arcade’s runtime ensures that authorization and governance keep running on every action, regardless of which protocol version is in play, or which new extensions a client supports.
The bottom line for builders
None of this is exotic. REST APIs are stateless by design and are the dominant standard due to its ease of use and scalability. People use REST everyday, whether they know it or not, and this change lowers the barrier for MCP to do the same. When the release lands, simple servers get simpler, multi-user scale stops fighting you, and Arcade can help support you as you migrate to the new version. Prepare now and you’ll be ready to enter the new MCP era as smoothly as possible.
From explainers to step-by-step instructions, Arcade is your guide to the largest revision to the MCP spec since launch. Click here for all of our coverage.
