The Model Context Protocol, the emerging standard for connecting AI agents to external tools, is shedding its local-first architecture in favor of true cloud-native scaling. The release candidate scheduled for July 28 removes protocol-level session affinity—a fundamental change that lets teams treat MCP services as ordinary cloud applications instead of stateful workloads requiring sticky session routing.

Why Session Affinity Was the Tax

Earlier MCP versions maintained per-connection session state: the server tracked every client interaction, and incoming requests had to route back to the same machine that initiated the session. This worked fine on a developer's laptop. In production, it became a scaling tax. You couldn't spin up a load balancer and distribute requests across multiple MCP servers without dedicating a server-to-client binding—defeating the point of horizontal scaling.

Muskan Bandta, cloud associate at ZopDev, puts it directly: "When your infrastructure team asks whether MCP services can scale like other cloud applications, the answer used to be 'not quite.' With the move to a stateless architecture, the answer is now yes."

The Stateless Contract

The new design flips the assumption: every request carries the information needed for any server to process it independently. Applications that still need context across requests can maintain that state—but explicitly, not hidden inside the protocol. That's a real trade-off: you gain portability and resilience, but you lose implicit session handling.

Amit Jena, AI development manager at Kanerika, notes this makes state visible to the LLM itself: "Instead of keeping application state hidden inside protocol sessions, the new design makes it explicit, allowing AI models to access, reason over, and pass that information between tools."

New Features in the Release

Multi Round-Trip Requests (MRTR): Servers can now request additional input mid-task without keeping a persistent connection open—a request-response exchange instead of a held line.

Routable transport headers: API gateways and networking infrastructure can identify and route MCP requests without deep packet inspection. This cuts overhead, lowers latency, and lets teams enforce rate-limiting and security policies using existing API management tools.

OAuth 2.1 and OpenID Connect: Updated authorization framework for cloud deployments.

Deterministic tool/resource caching: Improves LLM prompt-cache hit rates, saving token costs.

Deprecations and the Migration Trap

The protocol is dropping five legacy features over a year-long transition period: Roots, Sampling, Logging, HTTP+SSE transport, and Dynamic Client Registration. Backward compatibility is maintained—updated SDKs support both old and new versions—but Sampling's deprecation carries real consequences.

Sampling let MCP servers invoke the LLM through the client, meaning the server had a callback path into the model. Removing it means your server now calls the model provider directly. That changes your network architecture, your auth model, and your billing flow.

Jena warns: "The risk is that teams who haven't implemented sampling themselves won't know if a third-party MCP server they're depending on uses it." Finding these dependencies is the catch—they're hidden across gateway configs, deployment scripts, and monitoring dashboards. The code change is small; finding everywhere the assumption lives takes time.

Updated SDKs

Python, TypeScript, Go, and C# SDKs are updated and support both protocol versions, reducing immediate disruption risk. New clients can still talk to older servers, and updated servers still accept older clients.

What You Should Do Now

If you've deployed MCP in production, start auditing your architecture. Look for:

  • Session affinity or sticky routing in your deployment config
  • Any use of Sampling in custom or third-party MCP servers
  • Cost attribution logic tied to LLM callbacks through the client

If you're building new agents, start with the stateless model—it's the future. The transition gives you until mid-2027, but teams that wait will be scrambling when third-party servers force the upgrade.

Sources: