MCP 2026-07-28: The Shift Toward Stateless, Scalable AI Agent Infrastructure

The Model Context Protocol (MCP) is evolving from a developer-focused protocol for connecting AI models with tools and data into something much closer to production infrastructure for agentic applications.

On July 28, 2026, the MCP team released the 2026-07-28 specification, introducing one of the biggest architectural changes since MCP launched: a stateless protocol core.

The release also brings Multi Round-Trip Requests (MRTR), header-based routing, cacheable list responses, stronger authorization, a formal extensions framework, and updated Tier 1 SDKs.

For teams building AI agents and MCP servers at scale, these changes aren't just protocol-level details. They directly affect scalability, load balancing, caching, security, and how MCP fits into modern cloud infrastructure.

Why this release matters
MCP has grown rapidly since its launch.
According to the MCP maintainers, its Tier 1 SDKs are now seeing close to half a billion downloads per month, while the TypeScript and Python SDKs have each crossed 1 billion total downloads.
That level of adoption changes the engineering requirements.
A protocol used by a handful of experimental applications can tolerate architectural constraints that become painful when thousands of servers and clients are running in production.
The 2026-07-28 specification addresses many of those constraints.
The biggest change is simple to describe:

1. Stateless Protocol Core
Previously, Streamable HTTP MCP connections relied on an initialization handshake and a protocol-level session identified through Mcp-Session-Id.
That created an architectural dependency between a client and the server instance handling its session.
In large deployments, this can introduce additional infrastructure requirements such as sticky sessions, shared session storage, more complicated load-balancing strategies, and additional coordination between MCP server instances.
The 2026-07-28 specification removes the initialize/initialized handshake and the Mcp-Session-Id protocol-level session.
Instead, requests are designed to be self-describing, allowing an MCP request to be handled by any available server instance.
This means an MCP server can sit behind a standard round-robin load balancer without requiring protocol-level session affinity.

What does that look like?
Instead of thinking: Client → Session → Specific MCP Server
the architecture can now look more like: Client → Load Balancer → Any MCP Server Instance
That is a much more natural fit for cloud-native infrastructure.
An important distinction: stateless MCP does not mean that every MCP application must be stateless. If an application needs state—for example, a shopping basket, browser session, workflow ID, or long-running operation—the server can issue an explicit identifier and the client/model can provide that identifier in subsequent requests.
The important difference is that this state is now application-level state rather than hidden protocol-level session state.

2. Multi Round-Trip Requests (MRTR)
Stateless systems introduce an interesting challenge. What happens when a tool needs to interact with the client in the middle of an operation?
For example: “The tool is ready to delete this database. Do you want to continue?”
The new specification introduces Multi Round-Trip Requests (MRTR) to handle these scenarios without requiring a continuously open bidirectional protocol session.
Instead, the server can indicate that additional input is required. The client provides the requested information and retries the original operation with those responses attached.
This makes interactions such as user confirmations, missing parameters, elicitation, sampling, and client-root information much more compatible with a stateless architecture.
In other words, MCP is moving from “Keep the connection alive while we figure this out” toward “Represent the intermediate state explicitly and continue through another request.”

3. Header-Based Routing
Another important change is the introduction of HTTP headers for MCP method and tool identification.
Requests now carry Mcp-Method and Mcp-Name.
This might seem like a small implementation detail, but it has significant infrastructure implications.
A gateway, API management layer, WAF, or rate limiter can inspect these headers without having to parse the JSON-RPC request body.
That makes it easier to implement infrastructure-level policies such as routing, rate limiting, observability, and authorization.
The result is an MCP architecture that fits more naturally into the existing HTTP infrastructure ecosystem.

4. Smarter Caching
Caching becomes increasingly important as MCP deployments grow.
The new specification adds cache hints to responses from operations such as tools/list, prompts/list, resources/list, and resources/read.
Responses can now include information such as ttlMs and cacheScope.
This gives clients more information about how responses should be cached.
The specification also introduces deterministic ordering for list results, helping clients maintain stable caches and avoid unnecessary re-fetching.
For organizations operating MCP servers at scale, this can translate into fewer redundant requests and reduced load on upstream services.

5. Authorization Gets Stronger
Security is another major focus of the release.
The 2026-07-28 specification introduces several authorization hardening measures.
RFC 9207 issuer validation: Authorization servers should return the iss parameter, and clients must validate it before redeeming an authorization code. This helps protect against authorization-server mix-up scenarios.
Client ID Metadata Documents: The MCP ecosystem is moving away from Dynamic Client Registration (DCR) toward Client ID Metadata Documents (CIMD) as the preferred approach. DCR remains available for backward compatibility, but it is now formally deprecated for future MCP development.
Credential binding: Client credentials are bound to the authorization server that issued them, preventing credentials from being reused across different authorization servers.
These changes make MCP's authorization model more closely aligned with modern OAuth practices.

6. Extensions Become a First-Class Part of MCP
One of the most interesting architectural changes is the formalization of the MCP Extensions framework.
Rather than putting every new capability directly into the MCP core, extensions provide a mechanism for capabilities to evolve independently.
The 2026-07-28 release moves Tasks out of the experimental core and into the extensions framework.
Other extensions include capabilities such as MCP Apps, Enterprise Managed Authorization (EMA), and Tasks.
This creates a healthier evolution model for the protocol. Core functionality can remain stable while new capabilities can be developed, tested, and adopted independently.

7. Tasks Move to an Extension
Tasks are particularly interesting for AI agents because many real-world workflows are not instantaneous.
An agent might need to start a long-running operation, continue processing in the background, check its progress, and retrieve the result later.
The new Tasks extension introduces mechanisms such as tasks/get and tasks/update to support these workflows.
This is an important step toward MCP supporting long-running agentic operations, rather than only short request/response tool calls.

8. Deprecations and Migration Considerations
The release also introduces formal deprecations.
Roots, Sampling, and Logging are deprecated, while the legacy HTTP+SSE transport is also being phased out.
These features continue to work for now, but new implementations should avoid adopting the deprecated approaches.
The MCP team has also introduced a formal lifecycle policy with a minimum twelve-month deprecation window, giving developers more predictable time to migrate before capabilities can be removed.
This is particularly important for enterprises that need predictable upgrade cycles.

What does this mean for AI Engineers?
For developers building AI agents, the biggest takeaway isn't simply: “MCP got new features.”
It is that MCP is increasingly being designed around the realities of production distributed systems.
The new architecture makes it easier to think about MCP servers in familiar infrastructure terms:
Load Balancing → Requests can be distributed across instances without protocol-level session affinity.
Caching → Tool and resource metadata can be cached more intelligently.
Routing → Infrastructure can make decisions using HTTP headers.
Security → Authorization follows stronger OAuth-aligned practices.
Long-running Workflows → Tasks provide a foundation for asynchronous agent operations.
Extensibility → New capabilities can evolve without continuously expanding the protocol core.
Together, these changes make MCP increasingly compatible with the infrastructure patterns already used for modern APIs and cloud-native applications.

The Bigger Picture
The most interesting part of the 2026-07-28 release isn't any single feature.
It's the direction MCP is taking.
AI agents need access to tools, data, APIs, applications, and enterprise systems. As those integrations grow, the infrastructure connecting agents to those capabilities needs to be scalable, observable, secure, cacheable, routable, and extensible.
The latest MCP specification moves the protocol further in that direction.
The transition to a stateless core is particularly significant because it allows MCP servers to fit more naturally into standard cloud infrastructure instead of requiring specialized session-management patterns.
For organizations building agentic systems today, that could make MCP easier to operate at production scale.

Final Takeaway
MCP started as a way to standardize how AI applications interact with external tools and context.
The 2026-07-28 specification takes another step toward making it production-grade infrastructure for agentic systems.
The combination of stateless protocol architecture, Multi Round-Trip Requests, header-based routing, smarter caching, stronger authorization, formal extensions, long-running Tasks, and a clearer deprecation policy makes this one of the most significant MCP releases to date.
For anyone building AI agents, MCP servers, or enterprise AI infrastructure, this isn't just another version update.
It's a change in how MCP can be architected, deployed, and scaled.

Official Reference
MCP 2026-07-28 Release Announcement: https://blog.modelcontextprotocol.io/posts/2026-07-28/
Are you already building with MCP? What do you think about the move toward a stateless protocol core?
 