Review
MCP 2026-07-28 Stateless Architecture: Scaling Agent Servers Without Sticky Sessions
The 2026-07-28 Model Context Protocol release candidate introduces one of the biggest architectural changes since MCP launched: the transport core becomes stateless. Earlier HTTP MCP servers required an `initialize` handshake and an `Mcp-Session-Id`, forcing clients to remain attached to session state. At scale, that created sticky routing, Redis session stores, pod-failure problems, and poor serverless behavior. The new specification removes transport-level session management. Each request becomes self-describing and independent, allowing normal round-robin load balancing, transparent failover, serverless deployment, HTTP-header routing, cache controls, multi-round-trip interactions, and asynchronous tasks.
# MCP 2026-07-28 Stateless Architecture: Scaling Agent Servers Without Sticky Sessions
## Article Summary
The 2026-07-28 Model Context Protocol release candidate introduces one of the biggest architectural changes since MCP launched: the transport core becomes stateless. Earlier HTTP MCP servers required an `initialize` handshake and an `Mcp-Session-Id`, forcing clients to remain attached to session state. At scale, that created sticky routing, Redis session stores, pod-failure problems, and poor serverless behavior. The new specification removes transport-level session management. Each request becomes self-describing and independent, allowing normal round-robin load balancing, transparent failover, serverless deployment, HTTP-header routing, cache controls, multi-round-trip interactions, and asynchronous tasks.
---
MCP originally fit an environment like:
```text
one developer
β one local MCP server
```
That was ideal for stdio and local integrations.
Enterprise deployment is different:
```text
10,000 users
β AI gateway
β MCP cluster
β many enterprise tools
```
At that scale, transport sessions become infrastructure.
## Why the old session model was difficult
The older HTTP design used:
```text
initialize
β Mcp-Session-Id
β subsequent requests reuse session
```
Imagine three Kubernetes pods:
```text
Pod A
Pod B
Pod C
```
The first request reaches A.
The next round-robin request reaches C.
If session state lives only in A, C cannot continue.
The result is a session-not-found failure.
## Traditional workarounds
### Sticky routing
Pin a client to one pod.
This hurts load balancing and failover.
### Shared Redis
Store session state outside the pods.
This adds network calls, latency, operational complexity, and another highly available dependency.
### Session-aware gateway
Make the gateway understand protocol state.
That increases coupling and complexity.
## What the 2026-07-28 specification changes
The new core removes:
- the initialize / initialized handshake;
- the logical `Mcp-Session-Id`.
Each request carries its own metadata.
HTTP headers include values such as:
```text
MCP-Protocol-Version
Mcp-Method
Mcp-Name
```
The request body also includes client information and capabilities in `_meta`.
Any healthy server instance can process any request.
## Architectural consequences
### Standard round robin
Requests can go to any pod.
### Transparent pod failure
A restarted container no longer destroys a transport session.
### Serverless deployment
MCP servers can run naturally on serverless infrastructure and scale toward zero when idle.
### No protocol-session Redis
Shared state may still be required for business tasks, but it is no longer required merely to maintain an MCP transport session.
Google notes that major production servers such as GitHubβs MCP server have already moved away from Redis session storage under this architecture.
## HTTP headers become a governance layer
Promoting method and tool identity to HTTP headers allows gateways to perform:
- routing;
- rate limiting;
- auditing;
- policy;
- metrics;
without parsing the JSON body.
For example:
```text
Mcp-Name: delete_user
β require approval
Mcp-Name: search
β allow
```
The protocol also requires header and body values to match, reducing opportunities for policy bypass.
## Caching becomes explicit
The new design introduces fields such as:
```text
ttlMs
cacheScope
```
Clients can cache tool and resource lists for an explicit period rather than maintaining long-lived connections merely to detect changes.
This can reduce repeated requests significantly at enterprise scale.
## What about user confirmation?
Stateless systems still need multi-step interactions.
The new Multi Round-Trip Requests pattern allows a server to return an `InputRequiredResult` plus serialized `requestState`.
The client:
1. asks the user;
2. collects the answer;
3. resends the request;
4. includes the original request state.
Any server instance can continue the workflow.
State moves into an explicit application-level object rather than transport affinity.
## Long-running tasks
A database backup or refund may take many seconds.
The Tasks extension allows a tool call to return a `taskId` immediately and execute in the background.
The client can later use task primitives to retrieve status and final results.
The conversation does not need to hold one connection open.
## Stateless transport does not mean stateless business logic
A long-running refund still needs:
```text
taskId
status
result
```
stored somewhere.
The difference is that the datastore exists for business task state, not for protocol transport sessions.
That is a cleaner architecture boundary.
## Security improvements
The specification also strengthens several security mechanisms.
### Issuer verification
Clients validate authorization issuers.
### Resource indicators
Tokens identify the intended MCP resource server.
### JSON Schema 2020-12
Tool arguments can use richer schema composition and stricter validation.
These changes matter more as MCP moves from local development into remote enterprise infrastructure.
## Formal deprecation
The new ecosystem also introduces a predictable lifecycle:
```text
Active
β Deprecated
β Removed
```
Cloud observability increasingly moves toward OpenTelemetry rather than protocol-specific logging.
Again, MCP is beginning to look like cloud infrastructure rather than a local integration mechanism.
## Recommended cloud architecture
Older deployment:
```text
agent
β MCP gateway
β sticky load balancer
β MCP pod
β Redis session
```
New design:
```text
agent
β API gateway
β round-robin load balancer
βββ MCP pod
βββ MCP pod
βββ MCP pod
```
Long-running business task state remains separate.
## Migration approach
Do not migrate every server at once.
Start with:
1. inventory current protocol and session dependencies;
2. identify Redis and sticky-session assumptions;
3. upgrade one read-only server;
4. place it behind normal round-robin routing;
5. test pod restarts and autoscaling;
6. test user confirmation and long-running tasks;
7. migrate write operations only after idempotency and approval are verified.
Beta SDK support is already appearing across major languages, but production migration should still be staged.
## What to measure
Track:
- session-related errors;
- pod-failure impact;
- retry rate;
- long-task completion;
- infrastructure cost;
- latency;
- gateway policy behavior.
The strongest signal of success is that pod churn becomes invisible to clients.
## Conclusion
The 2026-07-28 MCP architecture is important because MCP is moving from a session-oriented integration protocol toward stateless cloud infrastructure.
The practical outcomes include:
- normal load balancing;
- no sticky sessions;
- easier serverless deployment;
- transparent failover;
- routable HTTP headers;
- better caching;
- asynchronous tasks;
- multi-round-trip interactions;
- clearer security boundaries.
If MCP remained optimized only for a developer laptop and local stdio server, it would stay a useful developer protocol.
A stateless, governable, horizontally scalable remote architecture gives it a realistic path toward becoming foundational infrastructure for enterprise agents.
For more practical MCP, agent architecture, AI gateway, and production engineering guidance, visit **Zyentor Picks**: https://www.zyentorpicks.com/.