For most of its life, MCP was a stateful protocol. An AI agent connected to an MCP server, established a session, and maintained that connection across multiple tool calls. The session carried context — authentication state, tool preferences, ongoing operations. It was a sensible design for a client-server world: you connect once, you stay connected, you do work.
That model worked. Until it didn’t.
The 2026-07-28 MCP Specification Release Candidate, published last week, is the largest revision of the protocol since its original launch. The headline change: MCP is now stateless at the protocol layer. No handshake. No session ID. Any request can hit any server instance. The implications ripple through every production AI system built on this protocol.
Why Stateful Was a Hidden Constraint
The session model made sense when MCP was primarily a single-agent tool-calling protocol. One agent, one server, one connection. The overhead of maintaining state was negligible.
But production AI systems in 2026 look nothing like that. An agent pipeline might have ten concurrent requests hitting the same MCP server fleet. An agent might need to hand off a task mid-operation and have a completely different process resume it. A gateway handling traffic from hundreds of concurrent users can’t afford sticky sessions — it needs to route requests to whatever server instance is available, not maintain a persistent bond with one.
Stateful MCP created a bottleneck here. The session was a single point of contention. Scale horizontally, and you had to replicate session state. Handle failovers, and you had to reconstruct context. The protocol that was supposed to standardize AI tool access had become an infrastructure constraint.
The stateless model removes that constraint entirely. The protocol now carries everything it needs in each request — authentication tokens, request context, tool invocation parameters. The server instance processing the request is irrelevant. You can route to instance A or instance Z and get the same result.
What Stateless Actually Means in Practice
Dropping “stateless” in a protocol spec sounds clean in theory. In practice, it required six Specification Enhancement Proposals (SEPs) to get right.
The first is the removal of session IDs. Previously, an agent would open a session, receive a session token, and include that token in subsequent requests. The server used the token to look up stored context. In the stateless model, every request is self-contained. The server processes it, returns a result, and moves on. There’s no state to look up, no session to maintain.
This sounds like it would break long-running operations. If an agent is in the middle of a 30-step workflow, does each step need to re-authenticate and re-send all context? The answer is yes — and that’s a feature, not a bug. Each step that re-sends its context is idempotent by design. If a request fails mid-operation, the client retries. If a server instance crashes, another one picks up the request without any special recovery logic.
The second SEP covers extensions as first-class citizens. MCP Apps, the hosted MCP extension ecosystem, gets first-class treatment in the spec. Extensions aren’t bolted-on afterthoughts — they’re part of the protocol definition. This matters for the ecosystem: if MCP extensions are protocol-level citizens, they’re portable across any MCP-compliant host, not tied to a specific vendor’s implementation.
The Horizontal Scale Advantage
For anyone running MCP servers at scale, the stateless model is a significant operational improvement.
Consider Aniket’s OpenClaw pipeline. The system runs a multi-agent workflow with a PM agent, a planner, an architect, a developer, and a QA agent. Each agent makes tool calls through MCP servers — filesystem access, API calls, browser automation. Under a stateful model, if the MCP server handling those calls crashes or gets overloaded, the session breaks. The agent either waits for recovery or needs explicit reconnection logic.
Under the stateless model, a failed request just gets routed to another instance. The MCP gateway handles this without the agent needing to know. The agent sends a request, gets a response, moves on. The infrastructure layer does the session management that the protocol used to own.
This shifts where complexity lives. Stateful protocols push complexity into the protocol layer — session management, state replication, connection pooling. Stateless protocols push that complexity into the gateway or client layer, where it can be managed with standard infrastructure tools. A load balancer in front of an MCP server fleet now works the way a load balancer works for any other service: route requests, handle retries, nothing special about AI.
Security in the Stateless World
SecurityWeek noted the enterprise implications: a major protocol overhaul shifts critical security responsibilities from the protocol itself to developers and platform builders. That’s accurate, but it undersells the actual tradeoffs.
With a stateful protocol, the server maintains session state — including authentication context. If the server is compromised, session hijacking becomes a concern. With stateless MCP, each request carries its own authentication. There’s no session to hijack. The attack surface changes from “steal a session token” to “forge a request” — which is a much more standard problem with standard solutions (request signing, token validation, mutual TLS at the transport layer).
The security posture improvement is real: stateless protocols are harder to exploit at the protocol layer because there’s less shared state to corrupt. What the security community rightfully flags is that application-level security becomes more critical. You can’t rely on the protocol to maintain a secure session — you have to validate every request individually. For production deployments, that means request validation, rate limiting, and input sanitization move from “nice to have” to mandatory.
What Doesn’t Change
MCP’s core value proposition remains intact. It’s still the USB-C of AI tool access — a standardized way for models to interact with external systems. The stateless change doesn’t alter the tool-calling interface, the resource model, or the prompt injection mitigations that vendors have been building out.
The change also doesn’t affect MCP’s relationship with A2A. These protocols occupy different layers: MCP handles tool access, A2A handles agent-to-agent collaboration. Stateless MCP still works with stateful A2A sessions because the protocols are orthogonal. An agent can maintain an A2A session with a peer while making stateless MCP tool calls to external services.
This is worth emphasizing: the MCP stateless change is an infrastructure improvement, not a philosophical shift. The agent experience — what it feels like to build with MCP servers and write tool definitions — doesn’t change. What changes is how those servers are deployed, scaled, and secured in production.
The Bet on Horizontal Architecture
The MCP 2026-07-28 RC is a bet that the future of AI infrastructure is horizontal. Stateless protocols work at any scale because they don’t carry the overhead of session management. They compose naturally with modern infrastructure — containers, load balancers, service meshes — because those tools were already designed around stateless communication.
This aligns with where the broader AI infrastructure world is heading. vLLM’s PagedAttention manages KV cache memory without process-level session state. llama.cpp’s token batching treats each request independently. The concurrency collapse analysis from earlier this week showed that even llama.cpp, often thought of as a single-sequence engine, matches vLLM’s latency at batch_size=1 because stateless processing removes the batching overhead that hurts single-request latency.
MCP’s stateless shift is part of the same pattern. Remove unnecessary shared state. Make each request self-contained. Let the infrastructure do what infrastructure does well — route, balance, scale.
The protocol that started as a way to give AI models access to tools has become infrastructure for the AI agent stack. The stateless model is the right foundation for that stack to scale.
Comments
Powered by GitHub Discussions via Giscus. Sign in with GitHub to leave a comment.