When I built AgentReview's MCP server, one of the first things I ran into was the session management problem. Every agent connection needed to maintain state somewhere, and the moment you tried to scale horizontally (even just adding a second instance) you had to start thinking about sticky sessions, shared memory, or some external store to keep everything coherent. It worked, but it felt like scaffolding I was building around a protocol that hadn't quite caught up to cloud-native expectations yet. The 2026-07-28 MCP specification changes that. The core is now fully stateless, and that changes more than the headline suggests.

What "Stateless Core" Means

The old MCP model assumed a persistent connection between a client and a server. Your agent would open a session, the server would remember that session, and all subsequent tool calls happened within that context. That works fine on a single box. The moment you put a load balancer in front of your MCP server, though, you've got a problem: request two might land on a different instance than request one, and that instance has no idea who you are.

The new spec flips this. All context a server needs to process a request is carried in the request itself, via standardized HTTP headers. There's no server-side session to maintain. Each call is self-contained. If you've worked with REST APIs or JWTs, this pattern is immediately familiar: the client owns the state and presents it on every call, rather than the server holding it in memory.

The practical result is that your MCP server is now just a stateless HTTP service. You can run it in a serverless function. You can put ten instances behind a round-robin load balancer and not think twice about which one handles a given request. You can deploy it to a Kubernetes pod, let the autoscaler spin up more replicas under load, and it just works, because there's nothing to synchronize between instances.

Why This Matters More Than It Sounds

I've been running AgentReview in a setup where the MCP server is essentially a single-threaded coordinator. That was fine for a hundred-odd engineers triggering PR reviews. The load is bursty, not sustained. But if you're building agent infrastructure that needs to handle production-scale traffic, the old stateful model was a real ceiling. You'd hit it fast.

Think about what scaling a stateful MCP server actually required before this spec. You needed either sticky sessions, which kill your ability to do real load balancing, or an external session store like Redis, which adds latency, ops overhead, and a new failure mode. Neither is terrible, but both are a tax you're paying just to work around a protocol constraint, not because your problem requires it.

With a stateless core, you get standard cloud-native scaling patterns without the extra work. Horizontal pod autoscaling in Kubernetes works without any session affinity configuration. Serverless deployments on Azure Functions or AWS Lambda are now viable because there's no warm session to worry about. Rolling deployments don't require draining active sessions. These aren't marginal quality-of-life improvements. They're the difference between agent infrastructure that feels bolted-on and infrastructure that behaves like any other service in your stack.

The standardized headers in the new spec are well-designed. Context like tool permissions, agent identity, and conversation scope gets encoded in request headers rather than server-side session objects. It's more verbose per request, but the tradeoff is worth it for anything running at scale. You can also inspect and debug it more easily: read a request in isolation and understand exactly what context the server is operating with, without needing to know the session history.

What You'll Need to Update (and What You Won't)

If you have an MCP server running against the older spec, the migration isn't trivial, but it's not a rewrite either. The tool definitions themselves don't change. Your actual tool logic, the functions that do the work, stays the same. What changes is the layer that handles connection management and context propagation.

In a .NET MCP server like the one backing AgentReview, you're probably managing session state in some middleware or a hosted service. That's the piece you're pulling out and replacing with header-parsing logic. Instead of looking up a session by ID and reading context from it, you're reading context directly from the incoming request headers. The shape of the data is similar; the location of the data is different.

The client side needs updating too. Whatever is instantiating your MCP client (your agent orchestrator, your LangChain wrapper, whatever) needs to attach the right context headers on each request rather than relying on an established session. If you're using an SDK that abstracts this, check for updates; most of the major ones are already shipping support for the new spec.

One thing to flag: if you had business logic that depended on server-side session state for something beyond MCP protocol requirements, like caching expensive tool results between calls within a session, you'll want to think about where that lives now. Moving it to a distributed cache or making the client responsible for passing it back is the right call, but it's not free. Better to know about that dependency upfront than discover it when the first load-balanced deployment starts behaving inconsistently.

My Take

The stateless MCP spec is the right call, and it should have been the default from the start. Stateful server protocols are hard to scale, and the agent use case almost always involves bursty, parallel workloads, exactly the scenario where statelessness pays the most dividends. Horizontal scaling, serverless deployments, and standard load balancing are table stakes if you're building something that needs to handle real production load.

For AgentReview specifically, this is a real unlock. Right now the MCP server is a single coordinating process. Moving to the new spec means I can run multiple instances without coordination overhead, which opens the door to parallel agent execution at a scale that wasn't clean to achieve before. I'll be migrating when the SDK support stabilizes, and I'll document what that migration looks like in practice.

If you're building MCP servers today, start designing for statelessness now even if you're not on the new spec yet. Avoid putting session-scoped state in your server that you don't have to. Make your tools idempotent. Pass context in rather than storing it. The migration will be easier later, and the architecture will be better for it regardless of which spec version you're targeting.