MCP dropped its session handshake and sticky sessions with it
Kevin Dubois wrote on the Quarkus blog on 21 September 2026 that the 2026-07-28 revision of the Model Context Protocol removes the stateful session, and that the 2.0.x line of the Quarkus MCP Server already supports it.
Until this revision a client had to perform an initialize handshake, receive a session ID, and stay on that specific server instance for the life of the connection. On one instance that is fine. Across more than one it forces sticky sessions or a shared session store purely to keep the connection alive.
The revision replaces that with self-contained JSON-RPC messages. Everything the server needs — protocol version, client identity, capabilities — moves into a _meta field inside each request. Over Streamable HTTP the same metadata is mirrored in headers (MCP-Protocol-Version, Mcp-Method, Mcp-Name), so a server can route or reject a request before parsing the body.

The part worth noticing
With no session state to track, any instance can serve any request — an MCP server scales horizontally like any other stateless HTTP service. That is the headline, and it is real.
The header mirroring is the quieter change and probably the more consequential one in operations. Putting protocol version, method and name in headers means the layer in front can make decisions without deserialising JSON-RPC: rate limits per method, routing by tool name, rejecting an unsupported protocol version at the edge. Infrastructure that had to be MCP-aware to do anything useful now needs only to read headers, which is what load balancers and gateways are already good at.
The cost is the usual cost of statelessness, and it is not mentioned in the post: every request now carries the identity and capability metadata that was negotiated once before. That is more bytes per call, and it moves the question of client identity from "established at handshake" to "asserted on each message" — which is a security property worth thinking about before it is treated as pure upside.