Stateless MCP in the 2026-07-28 Spec: What Changes for Agent Infrastructure

Model Context Protocol has evolved quickly. At the start, discussion focused on linking AI applications with tools and data. Since then it has gone through OAuth authorization, remote servers, large protocol revisions, registries, Client ID Metadata Documents and enterprise authorization. The 2026-07-28 specification shifts something more fundamental: the protocol itself turns stateless.

The initialization handshake is gone, and so are protocol-level sessions. A client no longer has to stay pinned to the server instance that accepted its connection. Each request carries enough information to stand on its own, and any compatible instance can answer it.

It could pass for a transport tweak, but the architectural impact runs deeper. Remote servers can behave like any cloud-native HTTP service, sitting behind ordinary load balancers, API gateways, WAFs, serverless platforms and scaled-out container fleets, with no session machinery specific to MCP.

The revision brings more besides: standard routing headers, discovery results that can be cached, Multi Round-Trip Requests, stronger authorization rules, OpenTelemetry conventions and a formal extension model. MCP looks less peculiar as infrastructure, which may be among the clearest signs of maturity. What follows covers the changes, why statelessness matters in production and what it implies for security, gateways and the broader agent runtime.

Why sessions hurt

MCP started with a modest problem: give AI applications a standard way to deal with tools, resources and external systems. For local clients and servers that worked naturally. Remote MCP changed things. Once servers ran across containers, Kubernetes clusters, serverless platforms and cloud infrastructure, protocol-level sessions triggered familiar distributed-systems headaches.

A client ran an initialization handshake, the server could hand out an Mcp-Session-Id and every later request had to preserve that relationship. At scale this could mean:

• load-balancer stickiness
• shared session stores
• failover that understands sessions
• long-lived connections
• extra lifecycle management

None of that is impossible to manage, as distributed systems have handled it for decades. What's worth asking is whether MCP had to create the problems at all, and with 2026-07-28 the answer increasingly is no.

The new specification drops the initialize and notifications/initialized handshake, protocol-level sessions and Mcp-Session-Id altogether. Requests carry whatever is needed to process them. Conceptually, the architecture changes like this:

Any compatible instance can handle the next request. That fits Kubernetes, containers, serverless functions, autoscaling, edge infrastructure and plain round-robin load balancing far better.

It's already happening in practice. Cloudflare has moved its MCP servers to this model and builds a fresh stateless server for every request. Google has called out the end of sticky sessions and shared session infrastructure as a major scaling gain. AWS AgentCore Gateway now supports the new protocol next to earlier MCP versions. So this is part of the deployment model today and not a theoretical architecture.

State doesn't disappear

A distinction matters here. Removing MCP sessions doesn't stop applications from keeping state. It means application state shouldn't hide inside the transport. Take an agent creating a workspace:

create_workspace()
  |
  v
workspace_id = ws_123

A later request can name the result explicitly:

update_workspace( workspace_id = "ws_123" )

The first request might land on server A and the second on server C. The application still has state, but it now has an explicit identifier and doesn't rely on an invisible tie between a client and one server process.

Protocol state and application state are different things. Explicit application state is easier to persist, audit, authorize, expire and reason about, and agentic systems gain a further perk: the agent can reason about the handle directly and carry it between tools and workflow steps.

Routing headers

Statelessness fixes one infrastructure problem, and another change may matter just as much for enterprise deployments. MCP now standardizes HTTP headers that describe the operation under way. For instance:

MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: delete_workspace

An intermediary previously might have had to open the JSON-RPC payload to learn what the agent wanted. Now the information is visible at the HTTP layer, and that opens some interesting options.

Security teams have reason to care. Agents are reaching more powerful tools, and the gateway becomes a natural place to enforce policy between intent and external effect. None of this removes the need for an agent harness or application-level controls. It arguably sets cleaner lines between protocol, gateway, harness and the systems behind them.

Asking for input without a session

Going stateless raises an obvious issue. What if a server needs more information before it can finish an operation? Picture a destructive call:

delete_environment(“production”)

The server may want confirmation first. Holding a bidirectional session open only for that exchange would erase much of what statelessness gains.

The specification's answer is Multi Round-Trip Requests (MRTR). A session no longer keeps the interaction alive. The server instead returns an input_required result that says what it needs. The exchange runs roughly like this:

Human approval, extra authentication, missing parameters, policy checks and similar interactive flows can all fit inside a stateless request model. That's most relevant to high-risk agent actions. Being able to call a tool doesn't entitle an agent to unlimited authority, and sensitive operations can add a decision point before running.

Caching and observability

Some of the quieter changes may count at scale. Listing operations, namely:

tools/list
prompts/list
resources/list
resources/read

can now return cache details such as ttlMs and cacheScope, and tool listings should come back in a deterministic order. This reads as routine HTTP optimization, yet AI systems benefit as well: stable tool definitions can improve prompt caching upstream at the LLM, whereas tools arriving in shifting orders or needing repeated rediscovery turn a small protocol quirk into added latency and token cost.

The specification also documents how to carry OpenTelemetry context, with familiar fields:

traceparent
tracestate
baggage

That's another case of MCP drifting toward infrastructure that DevOps and platform teams already know. The goal shouldn't be a separate observability stack built just for AI protocols. It should be making agent activity visible within the systems organizations already run.

Identity gets more important

Stateless requests don't lower the importance of identity. They make it important to get right on every single request. The new specification continues MCP's march toward established OAuth and OpenID Connect practices. That includes issuer validation meant to counter authorization-server mix-up attacks, and tighter credential binding.

The specification also makes formal a direction that had been building: Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents. CIMD had been emerging as the cleaner option while DCR hung on for compatibility, and the text now says so plainly. It's another maturity signal, since MCP avoids a private identity system and keeps converging on standards the web already uses. For enterprise agent deployments that base matters more as MCP grows from a few user-authorized integrations to large numbers of agents, clients, gateways and tools.

Registration is only a slice of authorization. At enterprise scale the harder question is which agents may reach which capabilities: hundreds of agents calling hundreds of services produce an N×M governance headache. Two mechanisms, Enterprise-Managed Authorization (EMA) and Identity Assertion Authorization Grants (ID-JAG), shift that call toward central enterprise policy. An enterprise identity provider helps decide whether an agent gets access, so individual MCP servers needn't ask users for consent one by one.

Stateless MCP doesn't replace that model. It sharpens the separation: transport state, client identity, authorization policy and application state are distinct architectural concerns.

What leaves the core

A telling part of the release is what MCP drops or relocates. Roots, Sampling and Logging leave the core model, and the older HTTP+SSE transport yields to Streamable HTTP. A formal extension framework arrives at the same time, so capabilities like Tasks can grow as extensions without inflating the protocol core. That implies a healthier boundary:

MCP doesn't need to become the whole agent runtime. The harness still owns the wider execution environment, and MCP supplies a standard way for that environment to interact with outside capabilities. A mature protocol isn't defined only by what it adds, but also by what it decides belongs elsewhere.

Stateless doesn't mean trusted

A stateless MCP server scales more simply, though stateless doesn't mean trusted: each request still crosses a security boundary. Prompt injection or poisoned context can still steer agents. Tools can still hold excessive privileges, credentials can still be misconfigured, and a supply-chain compromise can still bring in malicious servers or tools.

What changes is that the architecture gets cleaner. Instead of treating transport sessions as part of the security model, defenses can center on who the caller verifiably is, what policy the gateway enforces and which permissions each tool grants. Add explicit authorization and explicit resource identifiers, then validate inputs, require a human to approve sensitive actions, record telemetry for audit and keep the agent harness under control too.

One subtle point: client metadata isn't automatically identity. Whatever a client claims about itself in request metadata can't be weighed like an identity cryptographically established through OAuth or another trusted mechanism. Easier routing and inspection of MCP traffic lets security teams strengthen enforcement around the protocol without mistaking metadata for trust.

The bigger picture

The headline change in 2026-07-28 is simple: MCP is stateless. The larger story is what that permits. MCP requests behave more like ordinary HTTP workloads. Servers scale horizontally without session affinity. Gateways understand MCP operations through standard headers. Discovery can be cached. Interactive workflows continue through Multi Round-Trip Requests. Authorization keeps moving toward proven OAuth practice, observability can use OpenTelemetry and extensions leave room to evolve without turning the core into the entire agent runtime.

Individually these look like protocol improvements, and together they say more. MCP began by solving connectivity. Remote MCP made the ecosystem confront identity and authorization. CIMD and enterprise authorization now point toward governance, while stateless MCP deals with operability and scale. The protocol is growing less exotic and fits infrastructure people already know how to build, secure, observe and run. For something moving so quickly, becoming boring infrastructure might be the whole point.