MCP Without Sessions: Designing Agent Tools That Scale Sideways
The 2026-07-28 MCP release pushes the protocol toward a stateless core. Here is what that changes for tool servers, gateways, caching, and where your workflow state actually belongs.

Read the 2026-07-28 MCP release as a transport note and you will miss it. The move toward a stateless request-and-response core is an infrastructure decision, and it lands squarely on the teams who have to keep tool servers up at three in the morning.
Sticky sessions are the thing that quietly breaks every scaling story. They pin a conversation to one process, turn a routine deploy into a customer-visible failure, and make horizontal scaling a lie you tell your capacity planner. A stateless core removes the excuse.
Put workflow state where the workflow can own it
A tool server should never need to remember a caller in order to understand the next request. Push durable task state into an explicit application store or a task resource, and make every tool call carry enough identity and context to be authorized on its own merits. Retries get simple. Recovery gets simple. Autoscaling stops being a gamble.
- Design each request so any healthy instance can serve it, cold
- Use explicit state handles for long-running or resumable work — not connection memory
- Treat deterministic tool lists and cache hints as production performance features, not niceties
- Route and authorize on clear method and tool identity at the gateway, before business logic
- Plan the migration against the published deprecation window, not against a breaking deadline
Stateless is not context-free
This is the misread that costs teams a quarter. Agents still need plans, artifacts, permissions, and audit history. Nothing about the shift says throw that away. What changes is where it lives: those concerns become named, inspectable resources instead of implicit memory hiding inside a connection.
That relocation is the actual win. You can open a task and see its state. You can resume it after a crash. You can scale the tool layer independently of the business layer, because they are no longer welded together by a socket.
Caching becomes a first-class concern
Once discovery is cacheable and tool lists are deterministic, the cost profile of a busy agent fleet shifts. Clients stop re-negotiating capabilities on every turn, and gateways can make routing decisions without a round trip into application code. Budget for cache invalidation the way you would for any distributed system — a stale tool schema is a correctness bug, not a performance blip.
Run the upgrade like an infrastructure change
Before you touch an SDK version, inventory four things: every place you assume a session, every discovery call, every authorization check, and every long-running task. Then take one representative workflow all the way through — real traffic, real failures, a deliberate instance kill — and only then expand.
“A protocol upgrade succeeds when reliability and operability improve. Matching the version string is table stakes.”
Primary sources
First-party documentation and announcements used to ground this field note.