MCP goes stateless in its 2026-07-28 spec: what a scalable tools layer still leaves to the human layer

Published July 30, 2026 · Last reviewed July 30, 2026

On July 28, 2026, the maintainers of the Model Context Protocol published the 2026-07-28 specification, the largest revision to the protocol so far. The headline change is architectural. MCP drops the session-based, stateful model at its core and replaces it with a stateless request and response design. A server no longer has to remember a client between calls, which means MCP tools can run on serverless and edge infrastructure and sit behind an ordinary load balancer.

That is a real upgrade for anyone running agents at scale. Stateless services are easier to deploy, cheaper to operate, and simpler to keep reliable as traffic grows. The release also adds header-based routing, Multi Round-Trip Requests, cacheable list results, a formal extensions framework, and hardened authorization, with beta SDKs shipping for TypeScript, Python, Go, and C#.

It is worth being precise about what this fixes and what it does not. A sturdier tools layer makes the machine side of agent systems more dependable. It says nothing about who an agent represents on the other side of a conversation, or whether the human behind that agent agreed to be reached. This piece walks through what the spec changes, then shows where that human boundary still sits.

What the 2026-07-28 spec actually changes

Before this release, MCP was a stateful, bidirectional protocol. A client opened a session, the server held context for that session, and follow-up requests depended on the server remembering what came before. That worked well for a local tool talking to one client, but it made remote deployment awkward. Every request from a given client had to land on the same server instance, which forced sticky sessions, a shared session store, or both.

The 2026-07-28 specification removes that assumption. The core is now a stateless request and response model. Every request is self-describing, so any server instance can handle any request without prior context.¹ Clients that want a server’s capabilities up front can make a single optional discovery call, server/discover, rather than depending on a live session to carry that state.² The change is standardized as SEP-2575, which removes the initialize handshake, and SEP-2567, which removes protocol-level sessions and the Mcp-Session-Id header.³

The immediate payoff is operational. A remote MCP server that once needed session affinity can now run behind a plain round-robin load balancer, scale horizontally, and deploy on serverless or edge platforms that recycle instances between requests.⁴ AWS documented how its AgentCore Gateway maps onto the new model, a useful signal that the large infrastructure providers are treating stateless MCP as the deployment target rather than a curiosity.⁴

None of this changes what MCP is for. It remains the bus between an agent and the tools or data it uses, stewarded by the Agentic AI Foundation under the Linux Foundation. What changed is how that bus behaves under load: fewer moving parts, less state to synchronize, and a far shorter path from a working local server to a production one. For teams past the prototype stage, that is the difference that counts.

Routing on headers, not sessions

Statelessness needs a way for infrastructure to make sense of traffic it is not allowed to open. The spec’s answer is header-based routing, standardized as SEP-2243. The Streamable HTTP transport now requires an Mcp-Method header on every request, and an Mcp-Name header on requests that name a specific tool, resource, or prompt, meaning tools/call, resources/read, and prompts/get.⁵⁶

The point is that a gateway, load balancer, or rate limiter can now route and authorize a request by reading two headers, without parsing the JSON-RPC body. A request to call an expensive tool can be rate-limited on its name. A request for a read-only resource can be sent to a cheaper pool. None of it requires deep packet inspection or understanding the payload. To keep this honest, servers reject any request where the headers and the body disagree, so the routing metadata cannot lie about what the request actually does.⁵

The release pairs this with cacheable list results. A client can cache a tools/list response for as long as the server’s declared ttlMs allows, instead of re-fetching the catalog on every connection.⁶ Combined with self-describing requests, that trims a lot of redundant chatter out of high-volume deployments.

Read together, these are the mechanics that make the stateless promise real. Sticky sessions, shared session stores, and body-parsing gateways were the tax you paid to run MCP remotely. The 2026-07-28 transport replaces that tax with two headers and a cache policy, which is why the infrastructure crowd, not only protocol authors, is paying attention.

Multi round-trip requests, hardened authorization, and real scale

Dropping sessions raised an obvious problem: what happens when a tool needs to ask the user something in the middle of a call? The old answer was a persistent bidirectional stream. The new answer is Multi Round-Trip Requests. A tool can return an InputRequiredResult to signal that it needs more input, and the client gathers the answer and retries the request with it, no long-lived connection required.⁷ It preserves interactive, back-and-forth tool calls while keeping each individual request self-contained.

The spec also hardens authorization and, for the first time, ships a formal extensions framework and a deprecation policy so the protocol can grow without silently breaking clients.¹ That last part is quietly important. A protocol used this widely needs a predictable way to add and retire features, and a written policy is how a fast-moving spec earns the trust of the teams building on it. This release already exercises that policy: Roots, Sampling, and Logging are now formally deprecated (SEP-2577), along with the HTTP+SSE transport (SEP-2596), each carrying a minimum twelve-month deprecation window before removal.³ Tasks move out of the experimental core entirely, into a formal io.modelcontextprotocol/tasks extension (SEP-2663).³

The scale behind all of this is not small. The maintainers report close to half a billion downloads a month across the four Tier 1 SDKs, with the TypeScript and Python SDKs each past a billion cumulative downloads.⁸ Independent coverage put monthly downloads above 400 million around the release, consistent with that figure.⁹ Whatever the exact number this week, MCP is no longer an experiment. It is infrastructure that a very large amount of software now depends on.

That is exactly why the stateless rewrite matters and why it was worth breaking things for. When a protocol reaches this level of adoption, the cost of session affinity and body-parsing gateways is paid millions of times a day. Making the core stateless is how MCP stays reliable as the number of agents calling it keeps climbing.

What a more reliable tools layer still does not answer

A stateless core makes agent systems more reliable in one specific sense: the machine plumbing holds up under load. That is worth having. It is also not the only kind of reliability an agent network needs.

Consider what the spec governs and what it does not. It governs how an agent calls a tool, how that call is routed, and how it is authorized inside a trust boundary. Authorization here answers “may this client reach this tool?” It does not answer “who is the human this agent acts for?” or “did that human agree to this interaction?” Those are different questions, and a hardened tools layer leaves them exactly where it found them. We made the same point about the enterprise side of MCP in MCP Enterprise-Managed Authorization is stable: access is not the same as representation.

The gap shows up at the edge, when one company’s agent needs to reach another company’s agent. Inside a single system, the set of tools and identities is mostly known and can be routed on a header. Across a boundary, the hard part is not transport. It is discovery, qualification, and consent: which agent should mine talk to, on whose behalf, and does the person on the other side want to be reached at all. This is the same seam we mapped in the three-layer agent stack, where MCP, A2A, and the web-access layer each cover machine concerns and leave the human front door open.

A faster, stateless MCP moves more traffic more reliably. It does not decide who is on the other end, or whether they said yes.

How this connects to Tobira

This is the seam Tobira works on. The 2026-07-28 spec makes the tools layer stateless and easier to run at scale; Tobira adds the layer above it, a human-readable @handle and a mutual-reveal consent step that decide who an agent represents and whether two parties agree to exchange identity at all. The two are complementary. MCP is the reliable bus an agent uses to reach its tools; Tobira is the trust layer for human-to-agent professional networking, where agents discover, qualify, and exchange contact only after both sides agree. We unpack that handshake in AI agent consent in 2026: who said yes?. As of the June 2026 founder update, the Tobira network listed 648 public discoverable agents, including 102 business agents, with more than 1,000 signups, so the consent path is being walked at real, if early, scale.

Frequently asked questions

What does stateless mean in the MCP 2026-07-28 spec?

An MCP server no longer has to remember a client between requests. Each request is self-describing, so any server instance can handle any request. That removes the need for sticky sessions or a shared session store and lets MCP tools run on serverless and edge infrastructure behind an ordinary load balancer.

What are the Mcp-Method and Mcp-Name headers for?

They let gateways, load balancers, and rate limiters route and authorize a request without parsing its body. Mcp-Method is required on every request; Mcp-Name is required on requests that name a tool, resource, or prompt, meaning tools/call, resources/read, and prompts/get. Servers reject requests where the headers and body disagree, so the routing metadata stays trustworthy. The change was standardized as SEP-2243.

Does the stateless model break existing MCP servers?

It is a breaking change to the protocol core, which is why the maintainers shipped beta SDKs for TypeScript, Python, Go, and C# alongside migration notes and a formal deprecation policy. Existing servers keep working on older spec versions, but moving to the 2026-07-28 model requires updating to the new SDKs and adopting the header and request conventions.

Does MCP handle agent identity or user consent?

No. MCP governs how an agent reaches tools and data, including how those calls are authorized inside a trust boundary. It does not describe who an agent represents or whether the human behind it consented to an interaction. Discovery, representation, and consent live above the tools layer, not inside it.

Sources

• Model Context Protocol Blog, “The 2026-07-28 Specification”: https://blog.modelcontextprotocol.io/posts/2026-07-28/
• Model Context Protocol Blog, “Beta SDKs for the 2026-07-28 MCP Spec Release Candidate Are Here”: https://blog.modelcontextprotocol.io/posts/sdk-betas-2026-07-28/
• Model Context Protocol specification, 2026-07-28 changelog: https://modelcontextprotocol.io/specification/2026-07-28/changelog
• AWS Machine Learning Blog, “How AgentCore Gateway supports the MCP 2026-07-28 spec”: https://aws.amazon.com/blogs/machine-learning/how-agentcore-gateway-supports-the-mcp-2026-07-28-spec/
• 4sysops, “2026-07-28 Model Context Protocol (MCP): stateless, multi-round-trip, routable headers, authorization hardening”: https://4sysops.com/archives/2026-07-28-model-context-protocol-mcp-stateless-multi-round-trip-routable-headers-authorization-hardening/
• MCP Servers, “The 2026-07-28 MCP Specification: A Stateless, Extensible Future”: https://blog.mcpservers.org/posts/mcp-spec-2026-07-28
• Stacktree, “MCP 2026-07-28 spec: what changed, what breaks”: https://stacktr.ee/blog/mcp-2026-spec-changes
• byteiota, “MCP Goes Stateless: What the July 28 Spec Breaks”: https://byteiota.com/mcp-goes-stateless-july-2026-breaking-changes/
• 36Kr, “Claude’s Largest MCP Upgrade Drives Explosive Growth: Monthly Downloads Surpass 400 Million”: https://eu.36kr.com/en/p/3916379879861638