MCP's next release candidate drops sessions and the handshake, pushes state into handles

The next Model Context Protocol release candidate drops sessions and the initialization handshake, and it pushes state into handles so remote servers behave more like stateless HTTP. The New Stack reports the rewrite is the biggest update to MCP since the protocol launched, and lead maintainers have frozen the release ahead of it. Server implementations that relied on either mechanism have to change; the compatibility path is a rewrite of the server itself.

What the RC actually removes

Two pieces of the old machinery are gone. Sessions were the stateful thread that a client opened, held, and closed against a server. The initialization handshake was the boot sequence at the front of that thread: version negotiation, capability declarations, the exchange that let both sides agree they were the same kind of MCP.

The RC replaces both with handles. In this shape, a handle is a value the server hands back that carries whatever state the client will need to reference later. The client presents the handle on subsequent requests. The server is not required to remember anything between calls that is not encoded in the handle. That is what "stateless HTTP" means in this context: any request can go to any instance of the server, because none of them are storing the conversation.

For readers new to the history, this is a return trip in a specific way. MCP's earliest form ran as a desktop app talking to a local process over standard input and output. Sessions made sense there. Once servers moved out to networked services, the session model started to fight the deployment shape.

What this changes for CI/CD tools

If your platform ships an MCP server (for a CI system, a build tool, a policy engine), the operational surface flattens. Any load balancer will do. Blue/green swaps stop dropping open sessions on the floor, because there are no open sessions to drop. Scale-out is horizontal without a sticky-session rule in front of it. Restarts get cheaper.

If your platform is an MCP client (an agent, a code assistant, a pipeline runner that calls out to MCP tools), the client library has to be updated to speak the new protocol, and the assumptions the client made about "connected" state have to move somewhere else. Handles imply that whatever the client used to keep implicit is now explicit. The client library gets bigger. The server gets simpler.

Lead maintainers freezing the RC is the point in a protocol's life where downstream implementers get the exact shape they will need to conform to. Reading the diff now is cheaper than reading it after the client library shipped a release everyone pinned to.

What to watch out for

A stateless server model does not mean no server-side state. Anything a handle references still lives somewhere: a cache, a database, a token in a queue. Handles just move the responsibility for tracking identity out of the transport and into the payload. That is the same trade-off HTTP applications have been making for a long time.

Two questions worth answering before adopting the RC in a build pipeline:

1. How long is a handle valid, and what happens when it expires mid-workflow? Long-running CI jobs that stash a handle and come back an hour later behave differently against a server that keeps the referenced state around than one that reaps aggressively.
2. What is the size and sensitivity of a handle? If handles carry meaningful state, they leak whatever they encode when they show up in logs, error messages, or shell histories. Old-style session ids were opaque and short-lived. Handles may not be.

Neither answer falls out of removing sessions. Both need answers in each server implementation.

The migration is downstream

The RC being frozen does not mean the ecosystem has caught up. Every existing MCP server tied to sessions is a rewrite. Every existing client that assumed a handshake is a rewrite. Compatibility across old and new servers is somebody's problem, probably the client's, and that work is ahead of the frozen protocol, not behind it.

For CI/CD platforms that took an early MCP dependency, the timeline that matters is the one on the client and server implementations they run. The protocol's own release is already frozen.