The Model Context Protocol has been the connective tissue of agentic AI systems since Anthropic open-sourced it in late 2024. MCP servers give LLMs access to tools, resources, and prompts through a standardized interface — and the ecosystem has grown from a handful of official servers to over 200 in about eighteen months. That growth brings scale problems that the original protocol design didn’t fully anticipate.
On May 27, 2026, the Agentic AI Foundation published a release candidate for the next MCP specification with a stateless protocol core. That phrasing sounds like an implementation detail. It isn’t. A stateless protocol core is a fundamental architectural shift that changes how MCP servers handle connections, how agentic systems recover from failures, and what “long-running agent workflows” actually means in production.
What the Original Protocol Assumed
The original MCP specification (June 2025) was built around a stateful request-response model. A client connects to an MCP server, the server maintains session state for that connection, and each request carries enough context for the server to respond meaningfully. This works well for simple tool-calling workflows: the LLM sends a request, the server executes the tool, returns the result, and the connection either closes or continues.
The problem emerges at scale. When you have a multi-agent system where one agent spawns three sub-agents, each of which connects to four MCP servers, you now have twelve persistent server connections. Each of those servers is holding state in memory. If any of those agents crashes — and in long-running agentic workflows, they will — the state those servers were holding becomes orphaned. The next request from a recovered agent either gets a stale-state error or forces a full reconnection that re-executes whatever setup the server had already done.
For agent builders, this manifests as a class of bugs that are frustrating to debug: intermittent failures where a tool call that worked moments ago suddenly fails with a state-related error, particularly under load or after a transient network interruption.
What Stateless Changes
The 2026-07-28 release candidate introduces a stateless protocol core that decouples request handling from connection state. Under this model, each request is self-contained — it carries or references all the context the server needs to fulfill it, rather than relying on server-side session state accumulated over time.
This has three concrete implications for agent builders.
Connection resilience. When an agent reconnects after a crash, it sends a fresh request that the server can process without needing to recover a prior session. There’s no orphaned state, no partial setup to clean up, no risk of stale data from a crashed session leaking into a new request. For long-running workflows where agents might be interrupted and restarted multiple times, this is a meaningful reliability improvement.
Horizontal scaling. Stateful servers are inherently tied to the process that created them. A stateless MCP server can be load-balanced across multiple instances because any instance can handle any request — the request itself contains what it needs. This opens the door to MCP server deployments that scale horizontally with demand, rather than being constrained by the memory of a single process.
Auditability. Every request is self-contained, which means every request is independently logged and replayable. A stateless protocol makes it straightforward to replay a failed request against a different server instance, or to reconstruct exactly what happened by examining a single request payload rather than trying to reconstruct session state from server memory.
The Extensions Framework
The release candidate also introduces an Extensions framework alongside the stateless core. The MCP specification blog notes this explicitly: a stateless protocol core with extensions that let servers expose additional capabilities without bloating the base protocol.
This is a pattern that’s proven itself in HTTP — the core protocol is simple and stateless, and capabilities like authentication, compression, and encryption are layered on as extensions. MCP is taking the same approach: the base protocol handles the essential request-response cycle for tool calls, resources, and prompts, while servers that need richer behavior — streaming responses, complex authentication flows, subscription-based notifications — implement those as extensions.
For agent builders, the Extensions framework means you can rely on a stable, minimal MCP server interface while still being able to leverage advanced server capabilities when they’re available. A server that doesn’t support a particular extension simply doesn’t advertise it, and the client handles that gracefully.
What This Doesn’t Solve
A stateless protocol core is not a silver bullet for all the challenges in agentic systems. The protocol handles the communication layer, not the semantics of what the tools do. A server can be stateless at the protocol level while still maintaining stateful dependencies — a database connection, a file handle, a cache — that it uses to fulfill requests. The stateless core means the MCP layer doesn’t hold state, but the underlying systems that tools interact with still do.
Similarly, the Extensions framework doesn’t solve the discovery problem. If a server exposes its capabilities through extensions, clients still need a way to know what extensions a server supports before they can use them. The MCP Server Cards proposal — structured metadata documents exposed through standardized .well-known URLs — is designed to address this, but it’s still a proposal rather than a shipped feature.
Practical Impact for MCP Users
If you’re running MCP servers in a multi-agent system today, the stateless protocol core changes the failure recovery story. Agents that use tools via MCP will be more resilient to the restarts and reconnections that are inevitable in long-running workflows. If you’re designing new agentic systems, you can now assume that MCP servers can be load-balanced and scaled horizontally — a constraint that was difficult to work around with the stateful model.
The 2026-07-28 release candidate is exactly that: a release candidate, not a final specification. But the direction is clear, and the architectural principles it establishes are likely to persist into the final release. For agent builders, this is worth tracking not as a distant future possibility but as a practical improvement to the reliability and scalability of MCP-dependent systems that’s coming soon.
The MCP ecosystem has grown faster than almost any other AI infrastructure project. Keeping the protocol itself honest about what it can and can’t guarantee — starting with whether it actually needs to hold state — is part of what will let that growth continue without accumulating the kind of architectural debt that later becomes impossible to pay back.