MCP Goes Stateless: What the 2026-07-28 RC Actually Changes¶

If you've tried to run an MCP server properly on Kubernetes — not just kubectl apply a toy demo, but actually run it in production with horizontal scaling, rolling updates, and real traffic — you've hit the session problem. Sticky sessions at the load balancer. A Redis store bolted on to share session state across pods. Ingress rewrite rules that parse session IDs because your load balancer needs to route the same client to the same pod every time. It's the kind of infrastructure debt that accumulates quietly until someone tries to scale the thing and it falls apart.

The MCP spec release candidate locked on May 21st, and the headline change is that this whole problem goes away. MCP is now stateless at the protocol layer.

C4 Architecture Diagram

The session problem you're about to stop having

If you've run MCP servers on Kubernetes, you know the debt: sticky sessions at the load balancer, a Redis store bolted on to share session state across pods, Ingress rewrite rules that parse session IDs. The RC removes all of it. No more initialize/notifications/initialized handshake. No more routing the same client to the same pod. Stateless at the protocol layer means commodity HTTP infrastructure — and no more session-shaped technical debt.

What "stateless" actually means here¶

The old MCP model worked like a long-lived TCP connection. Client connects, server hands back a session ID, and every subsequent call carries that ID so the server knows where you are in the conversation. That's fine if you've got one server instance. The moment you need more than one — because you're scaling, or a pod restarted, or you're doing a rolling deploy — you're managing state across instances, and suddenly you're not running a microservice anymore, you're running a stateful application dressed up as one.

The RC removes the session handshake entirely. No more initialize/notifications/initialized dance. Instead, every request now carries its protocol version, client identity, and client capabilities in _meta. The server is pure request-response at the transport layer. Any request can land on any pod.

Here's the important part though — stateless protocol doesn't mean your application has to be stateless. If your MCP server needs to carry state across calls (say, a multi-step tool workflow, or a browser session), you mint an explicit handle from a tool call and have the model pass it back as an argument on later calls. The state exists, it's just managed explicitly as data, not implicitly in the connection. That's actually cleaner.

Routing just got boring (in a good way)¶

Previously you needed session-aware routing. With the RC, you route on the Mcp-Method header instead. This is a standard HTTP header that identifies the RPC method being called — tools/call, tools/list, whatever. You can route on it the same way you'd route on any other header in your Gateway API HTTPRoute:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: mcp-server
  namespace: platform
spec:
  parentRefs:
    - name: platform-gateway
  rules:
    - matches:
        - headers:
            - name: Mcp-Method
              value: tools/call
      backendRefs:
        - name: mcp-server-svc
          port: 8080

No session affinity. No custom Ingress annotations. Just header-based routing that your gateway already knows how to do.

Routing just became standard HTTP

Route on the Mcp-Method header — tools/call, tools/list, whatever. Your Gateway API HTTPRoute already knows how to match headers. No session affinity, no custom Ingress annotations, no special handling. If you're on Gateway API v1.5, this fits the routing model you're already using. If you're on Gateway API v1.5 (which went GA in April and promoted six features to Standard), this fits naturally into the routing model you're already using.

Your Deployment becomes boring too — three replicas behind a round-robin Service, HPA on CPU/RPS, standard rolling update strategy. Nothing special:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mcp-server
  namespace: platform
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    spec:
      containers:
        - name: mcp-server
          image: your-org/mcp-server:v2.0.0
          # No session store env vars. No Redis sidecar. Just your app.

If you've been running with sessionAffinity: ClientIP on your MCP Service, that's the first thing to drop. Check what you've got:

kubectl get svc -n platform -o jsonpath='{range .items[*]}{.metadata.name}: {.spec.sessionAffinity}{"\n"}{end}'

Anything that says ClientIP on an MCP-facing service can go back to None.

Caching tool discovery: the `ttlMs` field¶

This one's easy to miss but it matters. tools/list, prompts/list, resources/list — all of these now return a ttlMs field alongside a cacheScope. The ttlMs is how long the client can treat that response as fresh without re-fetching. cacheScope tells you whether it's safe to share across users ("public") or per-user only ("private").

In practice this means your agent doesn't have to call tools/list at the start of every turn to rediscover what tools exist. If your MCP server's tool inventory doesn't change often (and for most platform tooling it doesn't — the tools are relatively static), you can set a generous ttlMs and cut the latency of agent tool selection significantly. One fewer round-trip on every agent turn adds up fast when you're running thousands of turns a day.

The Extensions framework: Tasks moved out of core¶

Tasks were an experimental core feature in the November 2025 spec. They shipped, people used them in production, and the edge cases surfaced fast enough that the right answer was to pull them out of the core spec and ship them as an Extension instead.

The Tasks Extension reshapes the lifecycle around the stateless model: a server answers a tools/call with a task handle, and the client drives it with tasks/get, tasks/update, and tasks/cancel. Long-running operations — think triggering an ArgoCD app sync, waiting for a Crossplane managed resource to become ready, running a policy scan — can now be modelled as proper async tasks rather than blocking tool calls that time out.

If you're using Tasks today (the old 2025-11-25 model), the lifecycle API changed. Read the migration guide before July 28.

MCP Apps also ship as an Extension — they let servers render UI in supported clients. Worth knowing about but not something you need to implement for a platform tooling server.

Auth: finally aligning with how OAuth actually works¶

Six spec proposals harden the authorization model in the RC. The short version: token flows now align with standard OAuth 2.0 and OIDC patterns rather than MCP-specific auth inventions.

What this means in practice: if you're fronting MCP servers with Envoy, Cilium, or any other gateway that already does OIDC token validation, the auth handshake now speaks the same language. Less custom middleware. Less "why is my IdP rejecting this token shape" debugging. If you've been punting on MCP auth because it didn't map cleanly to your existing IAM setup, the RC is the right moment to revisit that.

The timeline and what you need to do¶

The RC window is ten weeks. Final spec publishes July 28, 2026. Tier 1 SDKs — TypeScript and Python — are expected to ship support within that window, which means before the spec finalizes. Start testing against SDK prereleases early, don't wait for the GA release.

Pre-July 28 migration checklist

Drop sessionAffinity: ClientIP from MCP-facing Kubernetes Services
Remove any Redis session store you bolted on — it's not needed at the protocol layer anymore
Update HTTPRoute/Ingress rules to route on Mcp-Method rather than session IDs
Update SDK dependencies to a version that implements the RC
If you use Tasks, read the migration guide — the lifecycle API changed
Set ttlMs on your tools/list response if your tool inventory is stable

Why this matters for the platform stack¶

The thing that changes most isn't the protocol mechanics — it's what you can now build with confidence. An MCP server that wraps your ArgoCD API, or surfaces Crossplane composite resources as tools, or queries your OPA/Kyverno policy engine — all of that can now be deployed like any other microservice on your platform. Same Deployment patterns, same HPA config, same rolling update strategy, same Gateway API routing. No special handling.

MCP servers now deploy like any other microservice

Same Deployment patterns, same HPA config, same rolling update strategy, same Gateway API routing. No special handling. No session store sidecar. No sticky routing workarounds. If you know how to run a stateless HTTP service on Kubernetes, you know how to run an MCP server.

That means the internal developer platform use case — where MCP becomes the interface layer between your engineers and your platform tooling — actually becomes practical at scale. You're not building a special snowflake deployment just for MCP. You're running stateless services. You already know how to do that.

The stateless core is the foundation everything else builds on. Extensions, MCP Apps, hardened auth — they matter, but they land on top of a protocol that can now run on commodity HTTP infrastructure without fighting your orchestration layer. That's the shift.

FAQ¶

Do I need to update all my existing MCP clients?

Clients that use the old session handshake need SDK updates. The RC SDKs handle negotiation gracefully — they detect whether the server supports the stateless model and adapt. Update to a prerelease SDK now and test against your existing servers before the July 28 final spec date.

What if I need stateful workflows?

Mint explicit handles from tool calls and pass them as arguments on subsequent calls. The state exists as data, not as connection. This is actually cleaner — your state is inspectable, transferable, and not tied to which pod happened to receive the first request.

Is the July 28 deadline hard?

It's the final spec date — the point at which the RC becomes the published standard. SDK support ships within the RC window so you can start testing now. Nothing breaks on July 28 if you haven't migrated, but you'll be running against a deprecated protocol model. Start with the checklist above and work through it before the window closes.

The MCP 2026-07-28 release candidate is available now at modelcontextprotocol.io. The final specification publishes July 28, 2026.