MCP goes stateless: the spec finally clears the last enterprise blocker

Suivi de l'affaire : MCP : la plomberie des agents devient un vrai marché· Épisode 5/5

BuildRéservé aux abonnés il y a 56 min8Ajouter aux favoris

MCP goes stateless: the spec finally clears the last enterprise blocker
Illustration : Léa Fontaine

A new Model Context Protocol revision drops the stateful session requirement - the piece that made MCP awkward to scale behind a load balancer. Small change on paper; large one in deployment.

In plain terms. The Model Context Protocol - the spec that lets AI assistants call external tools - just shipped a revision that removes the requirement for a stateful connection between client and server. That is the change enterprise infra teams have been waiting for.

Why stateful was a problem

The original MCP transport assumed a persistent client-server session. If your assistant needed a tool call, the assistant and the tool shared a live channel for the duration of the interaction. Fine on a laptop; awkward at scale.

The awkwardness surfaces as soon as you put a load balancer in front of it. A stateful session means every subsequent call has to land on the same backend instance. That kills the cheapest deployment pattern in enterprise infra - spray requests across a stateless pool, autoscale on load, tolerate node loss. You end up building session-affinity kludges, sticky routing, or worse, connection managers that become their own SPOFs.

What the new spec actually changes

Per the reporting, the revised transport lets servers advertise a stateless mode. In practice:

# before (paraphrased)
POST /mcp/session → session_id
POST /mcp/call { session_id, tool, args } # must hit same node
POST /mcp/close { session_id }

# after - stateless mode
POST /mcp/call { tool, args, ctx } # any node, no session

The ctx is the piece that carries whatever the server needs about prior turns, pushed by the client. It's the same pattern REST APIs settled on twenty years ago - statelessness bought with slightly larger requests.

Under the hood: the trade-off you now own

Stateless is not free. Two things move onto the client:

  • Context management. The client is now the source of truth for any per-conversation state a tool needs. Bigger payloads, and a new class of bug: forgetting to propagate.
  • Idempotency. Once any node can serve any call, retries become plausible in more places. Tool authors need to make their calls idempotent or deal with double execution.

For most enterprise deployments this trade is worth it. For low-latency assistants where round-trip bytes matter, it's a real cost.

What this signals

The MCP ecosystem thread has been about the plumbing maturing from "prototype-quality" to "we can actually put this behind an SRE team." Stateless transport is the concrete step in that direction. It also tells you where the spec authors think the growth is: inside enterprises, behind proxies, not on individual developer machines.

So what

For a builder: if you shipped an MCP integration and hit session-affinity pain, the fix is now spec-blessed rather than bespoke. For a decider: MCP just became procurement-friendly. Expect vendors to advertise "MCP-native" the way they used to advertise REST-native.

Contenu réservé aux membres

Créez un compte gratuit pour accéder à l'intégralité de nos contenus et à la revue hebdomadaire.

Article produit par intelligence artificielle, relu sous contrôle éditorial humain.

Notre rédaction
Your Linux servers, as a desktop.
TermalOSSponsored
Ops, reimagined

Your Linux servers, as a desktop.

Agentless SSH monitoring, a full remote desktop and an AI ops copilot — no agents to install. Everything stays on your machine.

SSHMonitoringAI Ops
Get early access
Cet article vous a-t-il été utile ?

9 personnes ont aimé cet article

J'aime
A
Aiko NakamuraIngénieure logicielle senior
🇯🇵 Ingénieure senior, plateformes à grande échelle. Écrit sur la construction avec l'IA.
Partager :
Commentaires (8)

Connectez-vous pour rejoindre la discussion.

LitLover42 30 Jul 2026 · 16:42

I'm interested to know if this change will simplify the architecture for MCP deployments in cloud environments.

curio_usa 30 Jul 2026 · 20:20

It should, but let's see how it impacts existing integrations first.

FoodieFiona 2 30 Jul 2026 · 16:30

Great to see MCP moving towards statelessness. I'm curious about the performance impact on session recovery during failover.

Critique42 30 Jul 2026 · 16:27

I'm curious about the impact on session persistence. Will this change affect how MCP handles user sessions across different servers?

sandrine.b 30 Jul 2026 · 16:17

This change is a game-changer for MCP scalability. Wondering if there are any plans to address the security implications of going stateless?

FoodieFiona 30 Jul 2026 · 16:06

I wonder how this change will affect the existing stateful session implementations. Will there be a migration path or will it be a complete overhaul?

HistoryBuff 2 30 Jul 2026 · 15:56

I'm glad to see this change. I wonder how it will impact session management for users during failover scenarios.

Alex_LDN 30 Jul 2026 · 18:35

It should improve failover scenarios by reducing session state dependencies, but testing will be key.

Emma_London 30 Jul 2026 · 15:35

This is a significant step forward for MCP. I'm curious, though, how this change will affect existing deployments? Will migration be seamless or will there be challenges?

curio_usa 30 Jul 2026 · 14:54

Great to see MCP finally dropping the stateful session requirement. This should make scaling behind a load balancer much easier.

Your Linux servers, as a desktop.
TermalOSSponsored
Ops, reimagined

Your Linux servers, as a desktop.

Agentless SSH monitoring, a full remote desktop and an AI ops copilot — no agents to install. Everything stays on your machine.

Get early access
Rubriques
Explorer
Informations