With Stateless MCP dropping tomorrow (July 28th, 2026), it’s important to understand the why behind the spec update/changes (because it’s a big one from a technical perspective) and what you will now be able to do with MCP that you couldn’t before.
In this blog post, you’ll learn the “why” and the engineering details underneath the hood for what makes the Stateless Spec.
The “Why”
Let’s use a k8s reference for explaining this as I’m sure many readers are Kubernetes enthusiasts. However, if you’re not, just think of a basic round robin.
Within Kubernetes, chances are you have many Pods (or at least two) running an application. These Pods, within a Deployment object, are configured and usable via the replicas parameters where you can specify one, two, or fifty Pods. The problem is a user/client/service can’t be expected to hit those Pods directly, and they’re ephemeral so you wouldn’t want that anyways. Instead, a Service sits in front of the Pods and load balances traffic to the backend (the backend being the pool of Pods). That way, traffic can flow through the load balancer and hit any Pod that contains the workflow/app information.
Now, think about that same thing, but for MCP. You would want an MCP server that is efficient, scalable, and highly available, right? Especially in production for human-managed-agents or autonomous agents that are interacting with MCP Servers as the main tool selection for what an agent needs to accomplish.
When it comes to MCP, we never had that.
MCP has been stateful which means:
1. One session across all requests
2. Session state lived on whichever server instance you first hit hidden in transport metadata and invisible to the agent.
3. No plain round-robin load balancing
4. A handshake is required at the first step to exchange protocol versions, capabilities, and session IDs
Every one of those constraints hurts you in production. Sticky sessions complicate scaling. Handshakes add latency and failure modes. Session state on one instance means restarting that instance takes down every conversation it was holding.
With Stateless MCP, you no longer have to worry about that. You will have:
- Horizontal scaling/round-robin LBs without sticky sessions
- No initialization/handshake
- Higher reliability/scalability
How It Works
With Stateless MCP, you get everything that was described in the previous section; horizontal scaling, plain round-robin LBs, no initialization/handshake, and failover is totally doable because there’s no session state to lose. Another key implementation here is performance. Handshakes at latency and sticky sessions make scaling incredibly complex (definitely can’t do basic round-robin load balancing).
The way that this is done is like any other stateless workload - by looking at the header of a request, not the body. With the Stateless MCP pec, SEP-2243 is introduced. It’s the “HTTP Header Standardization for Streamable HTTP Transport”, which enables putting the state information in headers instead of the body. The goal is to mirror key fields from JSON-RPC (that’s typically in the body of the request for Stateful MCP) payload into HTTP headers.
Standard headers to ensure the Streamable HTTP transport occurs will be needed:
And moving forward with Stateless MCP, these headers will be required.
Example call with a tools/call request:
POST /mcp HTTP/1.1
Content-Type: application/json
Mcp-Session-Id: 1f3a4b5c-6d7e-8f9a-0b1c-2d3e4f5a6b7c
Mcp-Method: tools/call
Mcp-Name: get_weather
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "get_weather",
"arguments": {
"location": "Seattle, WA"
}
}
}You can see a full breakdown of SEP-2243 here: https://modelcontextprotocol.io/seps/2243-http-standardization
Client Call To MCP
In Stateful MCP, you need to establish/initialize a session first before being able to call a tool.
POST /mcp HTTP/1.1
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"initialize",
"params":{"protocolVersion":"2025-11-25","capabilities":{},
"clientInfo":{"name":"my-app","version":"1.0"}}}The MCP Server responds with an Mcp-Session-Id once, and every subsequent request must carry it, pinning the MCP client/Agent to whichever instance issued it.
With Stateless MCP, the MCP Server tool call is self-contained, and that means any server instance can handle it. You can have an MCP Server scaled across Pods with a round-robin load balancer sitting in the front of it, routing requests to the backend (the MCP Server Pods).
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"},
"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}Because initialize is gone, a new server/discover method lets MCP clients fetch server capabilities when they need them up front.
Elicitation
TLDR of Elicitation is “ask for an approval mid-call”. That means, for example, a user/agent/both that currently doesn’t have access to the GitHub Copilot MCP Server may need access for a particular call (e.g. - using a search repositories tool).
Two SEPs to ensure Elicitation works with Stateless MCP:
- SEP-2260: Requests via the server can only be issued while the server is actively processing a request from an MCP client (an Agent, MCP Inspector, etc.). Now, a user is never prompted out of nowhere. The elicitation traces back to a client or an Agent started.
- SEP-2322: Multiple round-trip requests. Instead of an SSE stream staying open, the server returns
InputRequiredResult. The client gathers the answer from the input and any server instance can pick up the retry because it’s all in the payload via the header.
These implementations are very helpful, and quite frankly will help the adoption of Elicitation, because right now the pattern is that an MCP Server needs to ask the MCP client/Agent follow-up questions mid tool call. That means the request might land at a completely different MCP Server than the originator of the request. If the two servers have to coordinate, the exchange falls apart.
MCP App Extension
You see in the screenshot below how there’s a map with five quality coffee places to go to in New Jersey? And the map is interactive.
That’s thanks to MCP apps. MCP Apps, shipped with HTML interfaces that hosts render in iframe via a sandboxed environment, allow you to utilize MCP Server tools that are interactive. This is really great for things like diagrams, geography, travel, the weather, and anything where a visual representation makes the most sense for what you’re doing.
With Stateless MCP, there are now server-rendered user interfaces. That means the UI that’s rendered (and how you’re interacting with an MCP App) talks to the host (the application the user is in, like Claude Desktop or an IDE) via the JSON-RPC protocol (same protocol that’s used across MCP), so every initiated MCP App action goes through the same audit/consent path as a direct tool call.
Authorization Hardening
Something that has come up quite often across MCP clients is authentication and how it differs from one client to another. For example, you can use MCP Inspector, Hoot, MCP Jam, and realize that they all implement the OAuth spec, but in a different way. Because of this, authentication and authorization as a whole has been difficult to nail down for MCP across various environments.
With Stateless MCP, there are six SEPs that align closely with the OAuth 2.0 and OIDC specs to ensure a standard protocol is followed.
- SEP-2468: MCP Clients/Agents hitting an MCP Server must validate the
issparameter on authZ responses via the authorization server. - SEP-837: Clients/Agents declare their OIDC
application_typeduring DCR. - SEP-2352: Clients/Agents bind registered credentials to the issuing AuthZ server’s issuer and re-register when a resource migrates between authorization servers. This is useful when using multiple OIDC providers or the issuer moves.
- SEP-2207: Documents how to request refresh tokens via the OIDC authZ servers.
- SEP-2350: Clarifies scope accumulation during step-up authZ flow.
- SEP-2351: Clarifies the well-known URI for Authorization Server Metadata.
Wrapping Up
The Stateless MCP Spec allows engineers to have a dynamic they’re already used to; the ability to have something stateless or stateful. Stateful is still drastically important and it’s not that the concept of it needs to go away, but for cloud, DevOps, and platform engineers to utilize the same methods (e.g. - failover, basic load balancing, continued reliability) they’re used to, having an option to implement MCP in a stateless fashion will make MCP as a standard protocol far more adoptable.
If you want first-hand experience with the new MCP Stateless Spec, register for our free workshop here!
%20(1).png)
%20a%20Bad%20Idea.png)
