MCP goes stateless to make enterprise AI easier to scale

MCP moves to a stateless architecture to remove a production scaling constraint

The Model Context Protocol (MCP) is removing protocol-level sessions in its release candidate scheduled for July 28. This is the most important architectural change in the update. It addresses a practical problem: the previous session-based design did not fit cleanly with standard cloud infrastructure.

Earlier versions required an MCP server to maintain information about each client connection. That approach worked when an MCP server ran as a local process on a developer’s laptop. Production systems are different. Enterprises typically distribute requests across many servers to handle more traffic and maintain availability.

Session state made that distribution harder. A request could need to return to the server that held the relevant session information. Infrastructure teams therefore had to maintain session-aware routing, often called “sticky sessions,” instead of freely sending requests to any available server. That added operational complexity and limited straightforward horizontal scaling.

The new design removes this requirement at the protocol level. Each request contains the information an available MCP server needs to process it independently. Load balancers can therefore distribute MCP traffic across server instances without depending on a persistent protocol session. This brings MCP closer to the operating model enterprises already use for many cloud services.

Muskan Bandta, cloud associate at ZopDev, described the previous architecture as an “operational tax” once MCP moved beyond local development. She said the stateless design changes the answer when infrastructure teams ask whether MCP can scale in the same way as other cloud applications: “With the move to a stateless architecture, the answer is now yes.”

For executives, the important point is not statelessness itself. It is the removal of infrastructure-specific constraints as MCP moves from AI pilots into production. Enterprises can use established cloud practices for load balancing, scaling and distributed deployment rather than building around a protocol-level session requirement.

There is still migration work. Stateless MCP does not mean applications no longer need state. It changes who manages it. Any application that needs information to persist across several requests must manage that information explicitly. Organizations with infrastructure built around the old session model will therefore need to identify those dependencies before they can capture the full operational benefit.

Explicit state management gives enterprises more control over AI context

The stateless architecture also changes how MCP applications handle context. In the previous design, some state could remain inside a protocol session. Under the new model, applications that need persistent context must define, store and pass it explicitly.

This is an important design change for AI systems. MCP connects models with tools and enterprise data. Those interactions often depend on context from previous steps: what the user requested, which tool has already run, what information it returned and what should happen next. Making that state explicit gives developers more control over what information moves between models and tools.

Amit Jena, AI development manager at IT consulting firm Kanerika, said the change allows AI models to access, reason over and pass contextual information between tools rather than leaving application state hidden inside protocol sessions. He also expects the design to make AI workflows more portable, resilient and easier to orchestrate across distributed environments.

For enterprise leaders, explicit state can improve architectural visibility. Teams can decide where context is stored, which systems can access it and when it should be passed to another tool. Those choices matter for security, data governance and troubleshooting. They also matter when a workflow spans several services, cloud environments or third-party tools.

The trade-off is clear. MCP is no longer responsible for maintaining that state automatically. Application teams now own more of the state-management design. Poor implementation can still create inconsistent context, unnecessary data exposure or failures between workflow steps. The new architecture provides greater control, but enterprises must use that control deliberately.

This makes state design an application concern rather than a protocol constraint. That is the right direction for production MCP deployments. It separates the job of routing independent requests from the job of preserving business context, allowing enterprises to choose state-management methods that fit their own security, reliability and operational requirements.

MRTR keeps multi-step AI workflows possible without persistent connections

MCP’s move to stateless infrastructure creates a practical requirement. AI agents still need to conduct multi-step exchanges. A tool may start a task, discover that it lacks information, request more input and then continue. The new Multi Round-Trip Requests (MRTR) mechanism supports this pattern without requiring a persistent client-server connection.

Under MRTR, an MCP server can request additional information through a standard request-response exchange. Once it receives the required input, processing can continue. Amit Jena, AI development manager at IT consulting firm Kanerika, explained that this replaces the need to keep a connection active throughout the full interaction.

This distinction matters because stateless transport does not mean AI workflows must be single-step. MCP can remove protocol-level sessions while still supporting tasks that require several exchanges. The difference is that the interaction becomes a sequence of explicit requests rather than activity tied to one continuously maintained connection.

For enterprises, this design fits more naturally with distributed infrastructure. Individual requests can pass through load balancers, gateways and other standard networking components without requiring the same server connection to remain open for the full task. That can simplify deployment and make failures easier to isolate.

Executives should not assume MRTR automatically reduces latency or resource use in every workflow. Each additional exchange still has network and processing costs. The main benefit stated in the source is architectural: applications can support requests for additional input while preserving the stateless model.

The business implication is straightforward. MCP is separating long-running AI workflow logic from persistent network connections. That gives developers more flexibility to build interactive agents while infrastructure teams retain the scaling benefits of stateless services.

MCP adds enterprise controls for routing, identity and caching

The MCP update also addresses three production concerns: how requests are routed, how access is authorized and how repeated protocol information is cached. These changes make MCP easier to operate through infrastructure that enterprises already use.

Routable transport headers are the first improvement. They allow API gateways and other network infrastructure to identify and route MCP requests without examining their contents. Amit Jena, AI development manager at Kanerika, said this can reduce processing overhead and latency while allowing teams to enforce routing, rate-limiting and security policies through existing API management systems.

This matters at enterprise scale. API gateways often serve as enforcement points for traffic controls. Giving them routing information in a standard header reduces the need for MCP-specific inspection or custom handling. Infrastructure teams can apply established operational controls to MCP traffic rather than creating a separate management path.

Authorization is also being updated around OAuth 2.1 and OpenID Connect. OAuth 2.1 provides a framework for controlling delegated access, while OpenID Connect provides an identity layer. Their inclusion gives enterprises established mechanisms for deciding who or what can access MCP-connected resources. The update also includes interactive MCP Apps.

The third change is deterministic caching of tool and resource listings. MCP clients need information describing available tools and resources. Making these listings cacheable in a predictable way can increase LLM prompt-cache hit rates. The source says this could reduce token costs, although it provides no percentage or financial estimate for those savings.

For C-suite leaders, these changes are important because the constraint on enterprise AI is not only model capability. Production systems also need access control, traffic management and predictable operating costs. MCP is moving more of these requirements into forms that can work with established enterprise infrastructure.

The update does not remove the need for governance. OAuth-based authorization must still be configured correctly. Routing policies must reflect actual security requirements. Cache strategies must account for changes in tools and resources. The protocol provides better building blocks, but the enterprise remains responsible for how those controls are implemented.

Taken together, these additions strengthen MCP’s production case. Stateless operation addresses scaling, MRTR preserves multi-step interaction, and the routing, authorization and caching changes address practical requirements that become more important as MCP moves from developer experiments into managed enterprise AI systems.

Sampling deprecation changes MCP’s trust boundary and requires architecture reviews

MCP is deprecating five legacy features: Roots, Sampling, Logging, the older HTTP+SSE transport and Dynamic Client Registration. They will continue to work in the current version and other releases over the following year. This transition period limits immediate disruption, but enterprises should use it to identify dependencies now.

Sampling is the most consequential change highlighted in the source. Under the existing mechanism, an MCP server can ask the client to invoke a large language model on its behalf. The server therefore has an indirect callback path to the model without maintaining its own connection to the model provider.

Deprecating Sampling changes that design. According to Amit Jena, AI development manager at IT consulting firm Kanerika, a server that needs model access will instead call the model provider directly. He described the consequence clearly: “That changes your network architecture, your auth model, and depending on how you’ve built cost attribution, your billing flow.”

For an enterprise, this shifts several responsibilities. A server connecting directly to a model provider may require its own network access and credentials. Security teams must determine which servers can make those calls and what permissions they receive. FinOps teams may also need to reconsider how model usage is measured and assigned to applications, teams or customers.

The deeper issue is the trust boundary. Sampling placed the client between the MCP server and the model. Removing that mechanism changes which component holds authorization to use a model and where model-provider traffic originates. Existing security controls designed around the client-mediated approach may therefore need revision.

Third-party dependencies create an additional risk. An enterprise may never have implemented Sampling directly but could still rely on an external MCP server that uses it. Jena warned that teams may not know such dependencies exist. A source-code review of internal applications alone may therefore be insufficient. Organizations need an inventory of MCP servers and should confirm how each one interacts with models.

The roughly one-year compatibility period gives enterprises time to make these changes in a controlled way. It should be treated as a migration window rather than a reason to defer action. The priority is to identify Sampling dependencies, determine which servers will require direct model access, and update network, identity and cost controls before legacy support ends.

Backward-compatible SDKs reduce immediate migration risk, but hidden session dependencies remain the main challenge

The MCP update includes new SDKs for Python, TypeScript, Go and C#. They support both the old and new protocol versions. New clients can continue communicating with older servers, while updated servers can still work with older clients.

This backward compatibility is important because enterprises do not need to upgrade every MCP component at the same time. Teams can update clients, servers and supporting infrastructure in stages. That reduces the risk of an immediate service interruption and gives large organizations more control over deployment schedules.

Muskan Bandta, cloud associate at ZopDev, said this should make the transition largely incremental. The main exception is enterprises that built custom infrastructure around MCP’s previous session-based architecture. Those systems may contain assumptions that protocol compatibility alone cannot resolve.

The key migration constraint is discovering those assumptions. Amit Jena, AI development manager at Kanerika, said session management can be embedded across gateway configurations, deployment scripts and monitoring dashboards. As he put it, “The code change is small; finding everywhere the assumption lives is what takes time.”

This is an important distinction for executives planning migration budgets and timelines. An application team may update an MCP SDK quickly while the wider production environment still assumes that requests return to a specific server. Load-balancing rules, observability systems, deployment configurations and operational procedures could all retain dependencies on session behavior.

Backward compatibility therefore addresses protocol interoperability, not the full migration problem. It reduces pressure to coordinate an immediate upgrade across every client and server. It does not automatically identify or remove infrastructure built around persistent sessions.

Enterprises should approach the change as an architecture and operations audit, not only an SDK upgrade. Teams need to map where session state exists, determine which systems depend on it and decide where application state will live after migration. Monitoring and failure-recovery procedures should also be tested against the stateless design.

The overall transition should be manageable for most organizations because MCP preserves compatibility across protocol generations. The enterprises that face more work will be those with deeper customization around the old model. For them, the amount of application code changed may be small, but finding and removing hidden operational dependencies will determine the real migration effort.

Key executive takeaways

• Stateless MCP simplifies cloud scaling: Removing protocol-level sessions allows requests to run on any available server and reduces infrastructure complexity. Leaders should identify systems that still depend on session-aware routing before migrating.
• Explicit state creates more control and responsibility: Applications must now manage persistent context instead of relying on MCP sessions. Define where context is stored, who can access it and how it moves between models and tools.
• MRTR preserves multi-step AI workflows: Multi Round-Trip Requests let servers request more information without maintaining persistent connections. This supports interactive agent workflows while retaining the operational benefits of stateless infrastructure.
• Enterprise controls become easier to integrate: Routable headers, OAuth 2.1, OpenID Connect and deterministic caching improve compatibility with existing API, identity and cost-management systems. Teams should reuse established governance controls rather than create MCP-specific infrastructure where unnecessary.
• Sampling deprecation requires an architecture audit: Removing Sampling changes how MCP servers access models, affecting network paths, authorization and potentially billing. Use the roughly one-year transition period to find direct and third-party dependencies before legacy support ends.
• Backward compatibility reduces disruption but not migration work: Updated SDKs for Python, TypeScript, Go and C# support old and new protocol versions, enabling staged upgrades. Leaders should still audit gateways, deployment scripts and monitoring systems for hidden assumptions about persistent sessions.