On July 28, 2026, the Model Context Protocol specification underwent its largest revision since launch. The change: complete removal of session state from the protocol core.
No handshakes. No session IDs. No sticky load balancers. Instead, a fully stateless architecture that runs on standard HTTP infrastructure and scales to zero.
For developers building AI agents, this changes infrastructure costs, deployment complexity, and what's possible at scale.
The Problem: Sessions as Operational Tax
Before July 28, MCP required a handshake to establish a session. The server would return a Mcp-Session-Id header. That ID had to be attached to every subsequent request. The client and server were bound together—a sticky session.
In production, this created problems.
Sticky sessions mean requests from the same client always route to the same server. Load balancers can't use simple round-robin distribution. Instead, they need stateful routing, often through deep packet inspection or header-based affinity. The infrastructure becomes complex.
Session state also needs somewhere to live. In distributed systems, you either replicate it across servers (expensive) or store it in a shared database (adds latency and complexity). Either way, scaling requires managing session overhead.
For a development laptop running MCP locally? Not a problem. For production systems running millions of requests across multiple servers? Sessions become operational tax—complexity added by the protocol, not required by the application.
The Solution: Stateless By Design
The July 28 update removes sessions entirely. The initialize handshake is gone. Mcp-Session-Id headers disappear. Every MCP request becomes independent—all necessary context is contained in the request itself.
This single change unlocks infrastructure patterns that were previously impossible.
Round-robin load balancing now works. Without sticky sessions, requests can route to any server. Standard load balancers distribute traffic evenly. No state affinity needed. No deep packet inspection. Just simple, predictable routing.
Scale to zero becomes trivial. On Cloudflare Workers, Google Cloud Run, or Lambda, you pay for what you use. If your MCP server gets zero requests, you pay zero dollars. Stateless design makes this natural—any worker can handle any request without needing prior context.
Standard infrastructure works. Kubernetes deployments become straightforward. Auto-scaling works automatically. Horizontal scaling doesn't require session replication. The infrastructure patterns that work for every other HTTP service work for MCP.
How It Works: Stateless Request Patterns
Without session state, how do you handle workflows that require multiple interactions?
The answer: multi-round-trip requests. Instead of opening a stream and maintaining state, the client and server exchange multiple independent requests, each carrying all necessary context.
For interactive workflows—like asking an AI agent follow-up questions—the client tracks state locally. It makes a request, gets a response, uses the response to inform the next request. The server doesn't remember previous interactions; it answers each request independently.
For long-running operations, the new Tasks extension provides stateless handling. Instead of waiting for a tool to complete, the server returns a task handle. The client can then query task status with tasks/get, update it with tasks/update, or cancel with tasks/cancel. Each query is independent; no session tracking needed.
HTTP caching also becomes available. The protocol now includes ttlMs and cacheScope hints, allowing clients to cache tool/list responses and other cacheable data. Standard HTTP caching logic applies. No session overhead required.
Infrastructure Benefits: What This Enables
Cost reduction at scale.
Old MCP on production: You need sticky sessions, which requires either session replication across servers or a shared session store. Both add infrastructure cost. You can't easily scale to zero because the server must stay warm to handle session tracking.
New MCP on production: You run servers behind a standard round-robin load balancer. No session store. No replication overhead. On Cloudflare Workers, each request triggers a worker—you pay for compute time only. On Google Cloud Run, the same: pay-per-request with automatic scaling to zero.
Cost difference: From persistent infrastructure (servers + session storage) to truly serverless (pay only for what executes). For teams running MCP at scale, this is significant.
Deployment simplicity.
Before: You had to design for sticky sessions. This meant choosing load balancers carefully, considering session affinity, planning for session store failover. Production deployments became complex ops problems.
Now: You deploy behind any standard load balancer. Kubernetes works as-is. Auto-scaling policies apply directly. Horizontal scaling is automatic—add more servers and traffic distributes naturally. Deployment becomes a solved problem.
Global scalability.
Stateless design enables global distribution. A request can route to any server anywhere. No session affinity means no geographic routing complexity. Content delivery networks and edge computing become natural patterns for MCP.
Cloudflare runs MCP servers in Workers globally. Google Cloud Run scales across regions. Without session state, traffic routes optimally without worrying about session consistency or affinity.
Breaking Changes: What You Need to Know
This redesign is not backward compatible. Old clients won't work with new servers, and vice versa.
The handshake is gone, which breaks any code relying on initialize requests. Session tracking is gone, breaking code that persists Mcp-Session-Id. Multi-round-trip patterns are new, requiring client code changes. The Tasks extension is now official, not experimental.
The TypeScript SDK v2 splits into focused packages. Python v2 renames FastMCP to MCPServer. Go v1.7.0-pre.1 adds support. C# v2.0.0-preview.1 is available.
The important detail: this is not an emergency. The deprecation policy guarantees 12 months before legacy features are truly removed. Existing servers and clients continue working through the deprecation window. You have time to plan, test, and migrate.
Migration Path: How to Upgrade
First: Update your SDKs. The v2 SDKs include the new stateless patterns. Updating is the first step.
Second: Remove session management code. If your code relies on Mcp-Session-Id or initialize handshakes, that code is now unnecessary. Remove it.
Third: Switch to stateless patterns. For interactive workflows, adopt multi-round-trip request patterns. For long-running operations, use the Tasks extension. This is the core change.
Fourth: Test with standard infrastructure. Deploy behind a plain round-robin load balancer. Test Cloudflare Workers or Cloud Run. Verify that stateless routing works as expected.
Timeline: 12 months. You have until July 2027 to complete migration. That's ample time for development, testing, and staged rollout. Most teams can migrate within weeks; the 12-month window is generous.
Why This Matters
MCP is becoming the standard for connecting AI agents to external data and tools. As adoption grows, production deployments need to scale. Session state was fine for laptop development; it's a liability in production.
Stateless design fixes this. The same architectural pattern that enabled HTTP to scale globally now enables MCP to scale globally.
For teams building AI agents at production scale, this means: cheaper infrastructure, simpler deployment, and the ability to run on truly serverless platforms. For the MCP ecosystem, this means the protocol is ready for enterprise adoption.
The July 28 update isn't just a feature release. It's the moment MCP became enterprise-ready infrastructure.
For more on building scalable AI infrastructure, visit Bitroot.