MCP started as a standard way for AI applications to talk to tools and context.
Now that these systems are heading into production, a different question matters more: how do you scale MCP infrastructure without dragging around protocol state you don't need?
If you haven't read the basics, I covered them in What Is MCP and API vs MCP. This post assumes you know the shape of the thing.
The old mental model: sessions
The session-based flow looks like this:
AI Client ↓ MCP Server ↓ Session created ↓ Session ID returned ↓ Subsequent requests use that session
Reasonable at first. The server creates a session, the client gets an ID, and later requests are tied to it.
Then you run more than one server instance.
Load Balancer / | \ ↓ ↓ ↓ Server A Server B Server C
Request 1 lands on Server A. Request 2 lands on Server B. If the session only exists on Server A, Server B is stuck.
So now you need:
- Sticky sessions
- Shared session storage
- Session synchronization
- Extra failure handling
A protocol interaction has quietly turned into a stateful distributed system. Disaster is a strong word, but you've definitely signed up for work you didn't plan for.
The new direction: stateless protocol interactions
The more scalable idea is simple: give each request everything it needs to be processed.
No hidden protocol state. Any server can handle any request.
Request 1 → Server A → Response Request 2 → Server C → Response Request 3 → Server B → Response
The load balancer stops caring which server handled the previous request. That's the whole win.
Horizontal scaling gets boring
Boring is what you want from infrastructure.
Load Balancer / | | \ ↓ ↓ ↓ ↓ Server A Server B Server C Server D
More traffic? Add instances. One instance dies? The next request goes somewhere else. Nothing needs to preserve a session just to keep the conversation alive.
Where does application state go?
This is the part people get wrong.
Stateless protocol does not mean stateless application.
Take a shopping cart. The protocol doesn't need to remember the cart because a user called a tool earlier. The application owns that.
User adds item ↓ Application stores cart ↓ Cart ID = cart_789 ↓ Client sends cart_789 ↓ Any MCP server can process request
The state still exists. It just isn't hidden inside a protocol session.
Protocol state vs application state
Protocol state is whatever you need only to keep the communication mechanism working. If your infrastructure has to remember which server created a session so the next request succeeds, that's protocol state.
Application state belongs to the actual workflow:
- Shopping carts
- Conversation data
- User preferences
- Workflow and job status
- Database records
That belongs in systems built to hold it: databases, caches, object stores, workflow engines, application services. The protocol shouldn't turn into a database.
Why this matters for agents
One agent task can fan out into a lot of tool calls.
Agent → Tool A → Tool B → Tool C → Tool D → Tool E
Now picture thousands of agents doing that at once. You need infrastructure that handles the volume without ceremony.
A stateless model fits what cloud infrastructure already does well: load balancing, horizontal scaling, autoscaling, serverless deployments, container orchestration, and failure recovery. You operate it the way you operate everything else.
The bigger idea
This isn't a case against state. State is useful.
The principle is put state where it belongs. Keep communication independent. Keep application state explicit. Store durable state in systems designed for it. Then any instance can pick up the next request.
The interesting question isn't "is MCP stateless now?" It's what changes when an agent can call tools without your infrastructure needing sticky sessions to hold a conversation together.
Once protocol state and application state are separated, MCP fits the same cloud-native patterns we already use for distributed systems. AI infrastructure stops being a special category of software and becomes ordinary software engineering at scale.
Which is exactly where it should end up.
— Cheers, NP