Stateless MCP is cheaper to scale

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.

If you prefer YouTube, I made a video version of this post. Otherwise, read on!

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.

How MCP sessions became infrastructure

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.

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.

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.

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.

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.

What the new specification changes

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 supported versions and capabilities before making another call, but discovery no longer creates a mandatory protocol session.

This allows any compatible server instance to process a request without recovering the history of an MCP connection. A remote server that has no application state can sit behind an ordinary round-robin load balancer. The platform can add instances as traffic increases and remove them when traffic falls. A deployment can replace an instance without transferring the protocol sessions it owns, because the instance no longer owns any. The next request contains the information another instance needs to understand it.

Statelessness also makes MCP a more natural fit for serverless environments. A tool can run when a request arrives and disappear afterward without preserving an MCP session between invocations. Some tools will still be poor candidates for serverless deployment because of their runtime or application-state requirements, but the protocol is no longer the reason they need a long-lived process.

The broader revision follows the same operational direction. Streamable HTTP requests now include standard headers identifying the MCP method and, where appropriate, the name of the tool or resource. A gateway can use that information for routing and policy enforcement without parsing the JSON-RPC body first. List responses also provide explicit cache lifetimes, which gives clients and intermediaries a standard way to reduce repeated discovery traffic. These are separate changes within the specification, but together they make MCP traffic easier to operate using the HTTP infrastructure organizations already have.

GitHub’s migration shows where the savings come from

GitHub’s MCP server offers a useful example because the company has described what changed in its production architecture. When GitHub added support for the new specification, it removed its Redis-backed MCP sessions. That removed the database write previously performed during initialization and the database read performed on every later call.

This is a more concrete result than the general claim that stateless systems scale well. GitHub removed a shared infrastructure dependency from the protocol path and reduced the amount of database activity associated with each client. The company also stopped inspecting every JSON-RPC payload to extract information needed for logging and secret scanning, since the new HTTP headers make that information available before the SDK processes the request.

Other MCP providers will have different architectures, so they will not all remove the same components or see the same savings. Some were already operating in a stateless mode where their SDK allowed it. Others may have application state that still belongs in Redis. GitHub’s experience nevertheless demonstrates the category of improvement the specification enables. Protocol state that previously required storage and retrieval can leave the request path entirely.

The savings are partly financial and partly organizational. Running Redis has a direct cost, but the larger cost often comes from everything surrounding it. Teams have to provision it, monitor it, secure it, define retention behavior, and account for its failure modes. Removing a datastore from an architecture reduces the number of components involved in an incident and the number of assumptions a deployment process has to preserve. Those benefits are difficult to express as a simple cloud-pricing calculation, but they are familiar to anyone responsible for operating production services.

Stateful applications still have a place

A stateless MCP protocol does not require every MCP application to become stateless. Browser automation still requires a way to identify a browser created by an earlier call. A shopping tool still needs to know which basket an item should be added to. Long-running work still needs a durable identity that can be used to inspect or update it later.

The new design handles these cases through explicit state references. A tool that creates a browser can return a browser_id, and later calls can include that identifier as an ordinary argument. The same pattern works for a basket or task. The state behind the identifier may live in a database or another service that every server instance can access. MCP no longer creates that state automatically as part of the client’s protocol relationship.

This changes the scope of the infrastructure decision. A browser automation service may need a browser pool and a durable registry of active browsers because those resources are central to what the service does. A search service whose requests are independent can avoid persistent state entirely. Each server can adopt the architecture required by its application rather than the architecture implied by its transport session.

Explicit handles may also be more useful in agent workflows because the model can see them. An agent can distinguish between several browsers or pass a task identifier to a later step. It can include the relevant handle when another tool needs to operate on the same resource. A protocol session could preserve continuity, but that relationship was mostly hidden from the model and managed by the client implementation.

Why this matters

The move to stateless MCP is important because it makes the cost of operating a server more proportional to the work the server actually performs. Tools that need persistent application state will continue to pay for it. Tools that can process requests independently are no longer required to maintain protocol state simply because they are exposed remotely.

For infrastructure teams, this means that MCP servers can participate more naturally in existing deployment systems. Load balancers can distribute requests without preserving session affinity, and autoscaling systems can remove instances without first determining which clients depend on them. For web engineers, the request model is closer to the HTTP services they already build and operate. The protocol supplies the information required to understand the request, while application state is represented explicitly when a workflow needs it.

MCP’s original session model made more sense when the protocol was primarily associated with local processes and long-lived client relationships. Remote MCP servers have become important enough that the protocol now has to accommodate ordinary cloud deployment patterns. The 2026-07-28 specification does that by removing infrastructure requirements that were previously built into the relationship between every client and server.

The practical consequence is that remote MCP servers should become cheaper to scale. GitHub has already shown one version of that outcome by removing Redis sessions and database operations from its request path. Other providers will find their own savings depending on how they implemented the previous protocol. The underlying improvement is consistent: application state remains available where it serves the application, while the protocol no longer creates a session that every deployment must preserve.