Stateless MCP is cheaper to scale - Jeff Auriemma<br>Jeff Auriemma<br>Stateless MCP is cheaper to scale<br>MCP’s 2026-07-28 specification removes protocol sessions and the `Mcp-Session-Id` header, making remote MCP servers cheaper and easier to scale. This post explains the old session model, why it required infrastructure such as sticky routing and Redis, and how stateless MCP preserves application state through explicit handles.<br>Jeff Auriemma
August 05, 2026
The 2026-07-28 MCP specification makes the protocol stateless. The initialization handshake has been removed, along with the Mcp-Session-Id header and the protocol-level session associated with it. Most explanations of this change will understandably focus on protocol design, but the more useful headline is economic: remote MCP servers should now be cheaper and easier to operate at scale.<br>If you prefer YouTube, I made a video version of this post. Otherwise, read on!<br>That matters because MCP is moving beyond the environment where most developers first encountered it. A local MCP server communicating over standard input and output can rely on the lifetime of a process. The client starts the server, the two exchange information, and they maintain a relationship until the process ends. There is very little infrastructure to think about because everything is happening on one machine. Remote MCP servers have different requirements. They sit behind load balancers, run across several instances, and have to survive deployments and failures without asking every connected client to start over. The session model created costs that were easy to ignore locally and much harder to ignore in production.<br>How MCP sessions became infrastructure<br>In previous versions of MCP, the client began by calling initialize. That request established the protocol version and exchanged information about the capabilities of the client and server. A remote server could also issue an Mcp-Session-Id, which the client would include with subsequent requests. The server used that identifier to recover the protocol context associated with the client.<br>ALT
Sequence diagram showing a client initializing a server, receiving `Mcp-Session-Id: abc123`, then sending repeated `tools/call` requests with that same session-ID header and receiving results; a note emphasizes “same header, every request.”
This is similar to the server-side session model used by many web applications. A browser receives an opaque identifier in a cookie and returns it with later requests so the application can recover the correct state. MCP used an explicit protocol header rather than a browser cookie, but the deployment problem was familiar. Once a request depends on state created by an earlier request, the infrastructure has to ensure that the correct state is available wherever the next request lands.<br>One way to accomplish this is to configure sticky routing so that every request from a particular client returns to the server instance that created its session. That can work, but it also gives individual server processes a longer and more meaningful lifecycle. An instance may be serving very little traffic while still owning active sessions. Replacing it during a deployment can require session draining, and losing it unexpectedly may force clients to reconnect and initialize again. Traffic can also become uneven because the load balancer is constrained by relationships established earlier.<br>The other common approach is to put the session state somewhere every instance can reach. Redis is a typical choice. This allows requests to move between server instances, but now an MCP deployment includes a shared datastore for protocol bookkeeping. The initialization request creates a record, subsequent calls read it, and some later process has to decide when that record can be removed. The application may have no meaningful state of its own, yet the protocol relationship still creates storage and lifecycle requirements.
ALT
“Before 2025-11-25” architecture diagram: a client sends traffic through a load balancer using a sticky route to one of three MCP servers; all servers connect to a shared session store.
These are solvable engineering problems. Most infrastructure teams already know how to operate sticky sessions and shared stores. The question is whether every remote MCP server should require those solutions before the tool itself has demonstrated any need for persistent state. A search tool that independently answers each request has a very different application model from a browser automation tool that must preserve a live browser across several calls. The session model pushed both toward similar infrastructure.<br>What the new specification changes<br>The latest specification removes the initialization handshake and places the relevant protocol information on each request. Protocol version and client capabilities now travel through request metadata. Clients can use the new server/discover method when they want to inspect the server’s...