Stateless MCP: the end of heavy AI servers

The Model Context Protocol (2026-07-28 update) just went completely stateless. Here is what it means for the future of AI agents.

For two years, the Model Context Protocol quietly became the standard way AI agents talk to tools and data. It also carried a constraint nobody loved: a stateful handshake. Before an agent could do anything useful, it had to `initialize` a session and keep that connection alive for as long as the work continued.

That constraint just disappeared.

The 2026-07-28 revision of MCP, tracked as SEP-2575, removes the `initialize` handshake entirely. Every request is now self-contained. No open socket to babysit, no session to lose, no sticky routing to configure. It is a small change on paper and a large one in production.

**Why the old handshake was expensive**

Under the original design, a client and server had to keep a continuous line open. The server held the session state in memory: what tools were negotiated, what capabilities were agreed on, what the conversation had established so far. If that connection dropped, the state dropped with it.

For infrastructure teams, this meant sticky sessions. A load balancer could not freely route a request to any healthy server; it had to route it to the _same_ server that opened the session, every time, until the session ended. Losing that server meant losing the agent's context mid-task. Scaling meant running large, always-on servers that sat idle between bursts of traffic, because spinning one down risked killing a live session.

None of that maps cleanly onto how the modern web scales. Serverless platforms, autoscaling groups, and edge load balancers all assume requests are interchangeable and disposable. Stateful MCP fought that assumption at every turn.

**What changes now**

With the handshake gone, protocol version, client identity, and capabilities travel inside a `_meta` object attached to every request. The server no longer needs to remember who it is talking to. It is told, every single time.

State has not vanished. It moved. Instead of living invisibly in server memory, state now lives explicitly in the application layer. A server that needs to track something (a browser tab, a file handle, a long-running job) returns an explicit handle, something like `browserId`, and the client passes that handle back on the next call. The server can then rehydrate whatever it needs from a database, a cache, or storage, on any instance, at any time.

That single shift is what makes the rest of the update possible.

**Serverless MCP servers, for real this time**

Because connections close immediately after each request, MCP tools can now run on genuinely serverless infrastructure: platforms like Vercel Functions or AWS Lambda, where a function spins up, does its job, and disappears. There is no session to keep warm, so there is nothing forcing a server to sit idle waiting for the next message on the same connection.

The economics follow directly. You pay for the milliseconds a request actually takes to process, not for a server idling between calls. An MCP deployment that used to need a fleet of always-on instances can now scale to zero and burst to thousands of concurrent agents without anyone provisioning capacity in advance.

**The extras that came with it**

A few smaller changes ride along with the statelessness update, and they matter more than they look:

_Header routing (SEP-2243)._ The MCP method is now mirrored in an HTTP header on every request. A reverse proxy or gateway can route traffic based on the header alone, without parsing the JSON body first. That is a meaningful latency win at scale.

_A discovery endpoint._ Servers can expose `server/discover`, letting a client probe what a server supports, including backward compatibility with pre-2026-07-28 clients, before committing to a request shape.

_Multi-round-trip calls._ A server can now return an `input_required` state instead of blocking on an open connection. This is the piece that makes long, human-in-the-loop workflows practical without holding anything open.

**Why multi-round-trip matters**

Picture an agent booking a flight. It fills in passenger details, picks a seat, reaches the payment step, and needs a human to approve the charge. Under the old model, the server had two bad options: block the connection and hope the human clicks fast, or lose the session and restart the booking from scratch.

Under stateless MCP, the server saves its progress, returns `input_required`, and closes the connection. Nothing is held open. Whether the human approves in ten seconds or twenty minutes, the workflow resumes exactly where it left off, on whichever server instance happens to pick up the resumed request. The state was never in that server's memory to lose in the first place.

**The bigger idea**

There is a line worth sitting with here: a stateless protocol is easier to scale, easier to load-balance, and easier to reason about. State has not disappeared; it just became explicit. That is a trade most distributed systems engineers would take every time, and it is exactly the trade MCP just made.

The practical effect is that connecting an AI agent to a new application no longer requires thinking about session affinity, connection pools, or server sizing. It requires thinking about the request, the response, and the handle you get back. That is the same shape as ordinary web traffic, and it scales the same way ordinary web traffic does.

Removing a heavy piece of infrastructure tends to matter more than adding a flashy feature. Stateless MCP takes the biggest deployment headache out of the picture entirely. What is left is a protocol that behaves like the rest of the web: cheap to call, easy to distribute, and boring in exactly the way infrastructure should be.