Stateless MCP for SRE Agents

MCP is moving from local demos into production engineering workflows. If an incident agent depends on MCP servers for dashboards, tickets, runbooks, or deploy context, those servers need to scale and fail like ordinary HTTP services.

The Model Context Protocol team just published the 2026-07-28 release candidate with a stateless core. For SRE teams, this is worth tracking because it removes several pieces of operational friction from remote MCP deployments.

What Changed?

Older Streamable HTTP MCP flows started with an initialize handshake. The server could return an Mcp-Session-Id, and later calls had to carry that session ID. That worked for small deployments, but it pushed state into the protocol.

The new release removes the handshake and protocol-level session. Each request carries the protocol version, client metadata, and method information it needs. A tools/call request can land on any healthy server instance behind a normal load balancer.

It also adds request metadata headers such as Mcp-Method and Mcp-Name, cache metadata for list reads, W3C Trace Context propagation, and a multi round-trip request pattern for input.

Why SRE Teams Should Care

Stateless MCP fits the infrastructure SREs already operate:

• Simple scaling: round-robin load balancing is enough for most request paths.
• Cleaner failures: losing one backend instance does not destroy hidden protocol session state.
• Gateway policy: proxies can route and rate-limit by MCP method without parsing JSON bodies.
• Better observability: trace context can connect host apps, MCP clients, tool servers, and downstream APIs.
• Explicit state: application state becomes a handle passed as a tool argument, not invisible transport metadata.

That last point matters during incidents. If an agent starts a long-running task, the handle should be visible in logs, traces, and audit records. Hidden session state makes that harder.

Operational Rollout

Start by inventorying MCP servers that assume sticky sessions or long-lived server state. Check load balancer rules, gateway buffering, timeouts, and shared session stores.

For stateful workflows, move state into explicit handles. A tool can return an investigation_id, query_id, or task_id, then require later calls to pass it back.

Add gateway rules for Mcp-Method and Mcp-Name. Useful policies include separate rate limits for tools/list and tools/call, stricter controls for write-capable tools, and alerts on unknown methods.

Wire traces early. Propagate traceparent, tracestate, and baggage through the host app, MCP client, server, and downstream systems. During an incident, the trace should show which agent called which tool and what service it touched.

Migration Notes

Do not assume every client and server upgrades at once. Keep compatibility tests, pin server versions, and publish a short support matrix for internal tooling. Treat the release candidate as a planning signal unless your vendor or SDK has matching support.

Review authorization at the same time. Stateless transport does not remove the need for scoped tokens, identity-aware access, origin validation, and detailed tool-call logging.

Conclusion

Stateless MCP makes remote AI tool servers easier to run like normal cloud services. For SRE teams building agent-assisted incident workflows, that means simpler scaling, clearer state ownership, better gateway control, and traces that survive production failure modes.

Looking to automate infrastructure operations? Akmatori helps SRE teams reduce toil with AI agents built for real production workflows. For reliable global infrastructure, check out Gcore.