DEV Community

cheng zhang
cheng zhang

Posted on

MCP 2026-07-28 Stateless Architecture: Scaling Agent Servers Without Sticky Sessions

#ai #mcp #architecture #serverless

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:

one developer
→ one local MCP server
Enter fullscreen mode Exit fullscreen mode

That was ideal for stdio and local integrations.

Enterprise deployment is different:

10,000 users
→ AI gateway
→ MCP cluster
→ many enterprise tools
Enter fullscreen mode Exit fullscreen mode

At that scale, transport sessions become infrastructure.

Why the old session model was difficult

The older HTTP design used:

initialize
→ Mcp-Session-Id
→ subsequent requests reuse session
Enter fullscreen mode Exit fullscreen mode

Imagine three Kubernetes pods:

Pod A
Pod B
Pod C
Enter fullscreen mode Exit fullscreen mode

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:

MCP-Protocol-Version
Mcp-Method
Mcp-Name
Enter fullscreen mode Exit fullscreen mode

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:

Mcp-Name: delete_user
→ require approval

Mcp-Name: search
→ allow
Enter fullscreen mode Exit fullscreen mode

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:

ttlMs
cacheScope
Enter fullscreen mode Exit fullscreen mode

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:

taskId
status
result
Enter fullscreen mode Exit fullscreen mode

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:

Active
→ Deprecated
→ Removed
Enter fullscreen mode Exit fullscreen mode

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:

agent
→ MCP gateway
→ sticky load balancer
→ MCP pod
→ Redis session
Enter fullscreen mode Exit fullscreen mode

New design:

agent
→ API gateway
→ round-robin load balancer
   ├── MCP pod
   ├── MCP pod
   └── MCP pod
Enter fullscreen mode Exit fullscreen mode

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/.

Originally published on Zyentor Picks.

Top comments (0)