What Is Stateless MCP? How the New Model Context Protocol Works

The Model Context Protocol is one of the basic building blocks of how AI agents talk to the outside world. It is the plumbing that lets an AI reach into your calendar, your database, your company's Slack, or any other external tool, without someone building a custom connection for every single pairing.

On July 28, 2026, that plumbing got its biggest overhaul since it was first introduced. The 2026-07-28 specification makes MCP stateless by default, which means every request an AI agent sends is now completely self-contained. The server doesn't need to remember who you are or what you asked five seconds ago.

That sounds like a small technical detail. It is not. It is the difference between a protocol that works well on a developer's laptop and one that can run at the scale of Google Cloud.

What Is MCP?

MCP is an open-source protocol created at Anthropic by engineers David Soria Parra and Justin Spahr-Summers. It was open-sourced in November 2024 to solve what developers call the "M×N problem."

The problem is simple. If you have ten AI apps and each one needs to connect to a hundred different tools, you're looking at potentially a thousand custom integrations. MCP collapses that. Build the protocol once on the client side, once on the server side, and everything talks to everything.

The industry adopted it fast. OpenAI added MCP support in March 2025. Google followed in April. Microsoft and GitHub joined the steering committee by mid-2025. By the end of that year, MCP was donated to the Linux Foundation. The TypeScript and Python SDKs have each crossed one billion total downloads.

But here's the thing that doesn't get talked about enough: most AI agents don't fail because the underlying models are weak. They fail because the infrastructure around them isn't ready yet. Arcade, a startup that raised $60 million in June 2026 specifically to solve this problem, has built its entire business on that insight. And the old version of MCP was a big part of why the infrastructure wasn't ready.

The Problem With the Old MCP

In the previous version of MCP, connecting to a server required a handshake. The client said hello, the server handed back a session ID, and every request after that had to carry that ID back to the exact same server that issued it.

For a developer running MCP locally, this was fine. For a company trying to run MCP behind a load balancer with dozens of server instances, it was a mess.

Think about it this way. A load balancer's whole job is to spread requests across whichever server is free. But if every client is stuck talking to one specific server because that's where its session lives, the load balancer can't do its job. You end up needing sticky sessions, shared Redis stores, and complex routing rules. If the one server holding your session crashes, the session is gone, and your agent breaks mid-task.

This is a big part of why, despite all the excitement around agentic AI, we haven't seen more companies ship large-scale, first-party MCP integrations. The infrastructure was fighting itself.

Google ran into this wall early. When their teams tried to deploy MCP across cloud infrastructure, the session model broke the scaling patterns they depend on. Google's engineers co-founded the MCP Transports Working Group alongside Hugging Face, and Google's Kurtis Van Gent sponsored SEP-2575, the formal proposal that made MCP stateless.

What Stateless MCP Actually Changes

The handshake is gone. The session ID is gone. Every request now carries everything the server needs to process it, packed into a _meta field: the protocol version, the client's identity, and its capabilities.

A tool call under the new spec looks something like this:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": { "q": "otters" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "my-app",
        "version": "1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Any server instance can pick this up. No session lookup, no pinning, no shared memory store. It works the same way most ordinary websites already work, which is exactly the point.

If a client wants to check what a server can do before sending requests, there's a new server/discover endpoint. But calling it is optional. You can just start making requests, and if you call something the server doesn't support, you get a standard error back.

One clarification that comes up a lot: stateless MCP does not mean your application can't have state. If a server needs to carry information across multiple tool calls, it mints an explicit handle and the model passes it back as an argument on the next call. The state moves out of the transport layer and into the application, where the model can actually see it and reason about it.

How It Handles Mid-Call Conversations

One tricky scenario: what happens when a tool needs to ask the user something in the middle of running? Say an agent is about to delete three files and wants confirmation first.

In the old model, the server held a connection open and pushed the question back to the client. That doesn't work without sessions.

The new approach is called Multi Round-Trip Requests, or MRTR. Instead of holding the line, the server immediately returns a response that says "I need input before I can finish this." It bundles up everything needed to resume the task into a requestState payload. The client gets the user's answer, then retries the original request with the answer and the state attached.

Because the state is self-contained, the retry can land on any server instance. No pinning, no held connections. It is the stateless principle applied to an inherently interactive pattern.

What Developers Should Do Now

All four Tier 1 SDKs, TypeScript, Python, Go, and C#, support the 2026-07-28 spec as of launch day. A Rust SDK is in beta. TypeScript has also split into modular packages, with a codemod tool to automate migration.

The old stateful model isn't immediately broken. Servers can still implement the legacy initialize RPC for older clients. But the direction is clear, and deprecated features have a 12-month runway before removal.

For teams already running MCP in production, the biggest practical win is simpler infrastructure. Drop sticky sessions. Remove shared session stores. Put MCP servers behind a standard load balancer. Serverless deployment on platforms like Google Cloud Run or AWS Lambda becomes realistic in a way it simply wasn't before.

While model training keeps racing ahead, the infrastructure those models need is still catching up. MCP going stateless is the clearest sign yet that the plumbing is finally getting the attention it deserves. It really is happening; it's just been a little slower than the models themselves.