The latest release of the Model Context Protocol (MCP) specification has created a lot of buzz in tech circles. Why? Primarily because this AI communication protocol has now gone stateless! This shift from stateful to stateless impacts how developers of MCP servers and AI tools use the protocol moving forward. In addition, the change impacts companies that develop infrastructure like agent gateways and API providers that offer remote MCP servers.

This article looks at the change to statelessness in the new specification, the main benefit of going stateless, and what stateless MCP means for the industry in general.

MCP’s Move Towards Statelessness

Recently, the maintainers of MCP announced the official release of the latest version of the specification, version 2026-07-28. The release includes several changes. However, the main headline is that MCP is now stateless at the protocol layer. This move towards statelessness was achieved through the removal of the initialized handshake, the protocol-level session, and the Mcp-Session-Id header.

Emmanuel Paraskakis, CEO and API product strategy consultant at Level 250, explains in a LinkedIn post that without these components, every MCP request carries its protocol version and capabilities. And because of these changes, the “cross-call state becomes explicit handles your server mints and accepts as ordinary tool arguments.”

With stateless MCP, you no longer need sticky sessions at the protocol layer. Your server runs behind plain HTTP load balancers.

The Main Benefit of MCP Statelessness: Scalability

If you look at the discussions online about the protocol’s move to statelessness, you’ll find that most of them mention scalability as a key benefit.

A recent Google for Developers blog article by Kurtis Van Gent at Google Cloud Data and Alan Blount at Google Cloud AI explains how the original stateful protocol model created a sessions bottleneck for agentic AI. This model required a stateful initialization process to connect to an MCP server over HTTP.

Each server would respond with an Mcp-Session-Id header. Clients had to include a unique session ID with every request to make subsequent tool calls or resource queries. This session ID requirement meant the client was pinned to a specific container or pod that held its in-memory session state.

Christian Posta, author, international speaker, and VP, Global Field CTO at Solo.io, explains in an agentgateway blog article that with the old protocol, sessions pinned a client to a specific server instance. And without proxies successfully tracking and mapping session IDs, you were effectively limited to a single replica per MCP server.

“agentgateway solved session mapping, but the draft [version 2026-07-28] makes the whole problem disappear for everyone: with no Mcp-Session-Id and self-contained requests, any request can go to any replica,” Posta says in the article. “Scaling an MCP backend horizontally becomes ordinary load balancing, and that’s a real win.”

Decoupling state from the transport layer allows the protocol to meet the scalability requirements of platforms that handle millions of concurrent queries like Google Cloud and allow enterprises to scale agentic systems for real-world applications.

How MCP Statelessness Impacts Developers

The consensus is that MCP’s shift to statelessness is a good thing. However, this change impacts different developers in different ways.

Responsibilities Shifted

Moving towards statelessness means that responsibilities in different areas have shifted. For example, it makes different parts of the architecture responsible for state and recovery.

David Crowder, Founder and CEO of Right Side Up Advisors, says on LinkedIn that this shift is usually where production migrations get underestimated. “Changing the protocol is one thing; understanding where the old assumptions about state, retries, routing, and failure recovery actually live in the system is another,” Crowder states.

Faisal Feroz, Chief Technical Architect at NielsenIQ, also comments on LinkedIn that MCP going in the direction of stateless with headers (routing fields now live in HTTP headers) “makes sense operationally, but it pushes more responsibility onto the gateway layer to get identity and session handling right.”

Feroz also says that he “would rather see that complexity centralized in something like an agentgateway than duplicated inside every agent implementation.”

In a recent VentureBeat interview, Den Delimarsky, a lead maintainer of MCP, explains that the move to statelessness shifts the responsibility of creating and managing state to the developers. They can manage the state however they see fit for their environment.

Posta mentions on LinkedIn that a server may need to signal to the client that it needs more information, the state having to live somewhere. In this case, managing state may involve implementing the Multi Round-Trip Requests (MRTR) message pattern. It’s up to developers to manage where state goes and how servers and their clients handle it.

More Work for Some, Less for Others

The stateless version of the protocol is easier to implement than the previous stateful version. So, if you are starting from scratch, using the latest version should be straightforward and less time-consuming than the old version. However, if you’ve already written a lot of stateful code so that MCP connects your application to a large language model (LLM), you’re in for a lot of work if you want to switch to stateless.

If you don’t want to switch to the stateless version, you don’t have to — stateful MCP will continue to work (at least for the time being). Breaking changes will only happen if you move from stateful to stateless MCP.

The change to statelessness and routing fields in HTTP headers also means that any developer building an MCP server, especially those exposing their server from an MCP/agentgateway, needs to spend some time strengthening security. This new version introduces new attack vectors, particularly through header/body mismatching.

Posta explains in the same blog article that the new spec makes a naive header-only proxy more dangerous, not less. So, you shouldn’t let a plain L7 load balancer or API gateway make authorization or policy decisions based on headers alone.

“The mistake is extrapolating from routing to policy and trust,” Posta says. “Once you decide the header is the source of truth, four things break: security, authorization UX, federation, and identity.”

The latest MCP specification expects the server to have a reliable identity layer in the path. And it’s up to developers to make sure they have one in place.

Slightly Bigger Payloads to Deal With

VentureBeat also interviewed MCP co-creator David Soria Parra, who explained that one of the trade-offs for statelessness is larger payloads. Much of the state doesn’t go away. Instead, it’s sent to and from the server through a network connection. It travels as part of the data transmitted at the transport layer. Parra says that the payloads are compressible and fairly small compared to an HTTP request on the web.

Most AI applications will see little impact from these larger payload sizes. However, some will see an impact on bandwidth and latency even with compression. For example, developers building AI agents that often have lengthy conversations and require a lot of tool calling will feel the added state in payloads.

What Stateless MCP Means for Gateway and API Providers

A few MCP/agent gateways like agentgateway and AgentCore Gateway handle all MCP versions, including stateless 2026-07-28.
However, stateless MCP adoption among gateway providers is still in its early days. This version of the protocol has only been available for a little over a month. It will take some time for it to become widely adopted across the broader gateway and AI-infrastructure ecosystem.

On the other hand, API providers that also offer MCP servers seem to be on a slightly faster track when it comes to supporting the new protocol version. Cloudflare, GitHub, and Google Cloud have all taken the lead in this regard.
The same day as the MCP 2026-07-28 official release, Cloudflare announced that its product-specific MCP servers supported the new version. The GitHub MCP Server supported the stateless protocol version ahead of its official release. And a day after MCP’s official announcement, Google staff software engineer Averi Kitsch posted on Medium that MCP Toolbox for Databases (v1.8.0+) natively supports MCP 2026-07-28 along with its SDKs in Python, Go, and JS/TS.

Big tech companies like the ones mentioned above have the resources to add support for stateless MCP quickly, and in many products. All these MCP servers currently support both the new and previous versions of MCP.

Given how fast these companies can move, it’s worth asking whether other API providers should immediately replace their stateful MCP servers with ones that are entirely stateless — no fallbacks to stateful MCP. The short answer is probably not.

Pamela Fox, Principal Cloud Advocate (Python) at Microsoft, recommends that servers support both the stateful and stateless protocols if possible. “For existing servers, they may start seeing ‘weird traffic’ from clients that attempt to use the new stateless protocol with them – i.e. routes they don’t support,” Fox commented on LinkedIn. “But then those clients should fall back to the stateful protocol once they realize that the server doesn’t speak stateless.”

The direction for LLM-driven application development is clearly headed towards “stateless as the default.” The protocol maintainers, major cloud platforms, and fast-moving API providers are all pointing that way. However, most API providers may want to hold off shutting down their stateful MCP servers in favor of stateless ones until more infrastructure providers, gateways in particular, adopt stateless MCP more broadly.

MCP is Moving Closer to How the Web Works

Statelessness, HTTP headers, load balancers, plain request/response — these components make the web work. Now MCP follows this paradigm. The new version of this AI protocol makes scaling LLM-driven applications, particularly those relying on MCP servers, easier to build and scale. It does create more work for MCP server developers who want to move from stateful to stateless. AI-infrastructure companies and API providers with MCP server products need to make some well-timed decisions about statelessness as well. However, the reward for moving to stateless MCP is a level of scalability that meets the requirements of agentic systems.