What MCP Actually Does
The Model Context Protocol is the plumbing layer that lets AI models reach outside themselves. Without it, every connection between a chatbot and your calendar, database, or internal tools would require a custom-built pipe. Engineers would be writing bespoke integrations for every possible data source, and we'd still be stuck in that world.
MCP changes that. It gives AI models a secure, standardized way to access external data sources and services — the same way TCP/IP gave applications a common language for networking. Except instead of packets, we're talking about context. Instead of routing bytes, we're routing meaning.
And next week, that protocol gets a significant update. It won't be visible to end users clicking around in their chat interfaces, but it could reshape how the entire ecosystem scales. That's usually where the interesting work happens anyway.
How Session IDs Work Today
Here's the handshake, stripped down: when an MCP client like Claude first connects to a server, it sends a "hello." I'm Claude. Here's my version. Here are my capabilities.
The server replies with its own capabilities and hands back a session ID — a token that says "I know who you are, and I'll remember this conversation."
From then on, every request the client sends includes that session ID. The server uses it to maintain context across the exchange. Sometimes the ID expires, and the client has to notice, request a new one, and carry on. This works fine in theory.
It also works fine when you're running one server for one user. Or ten users. The problem starts when you actually try to ship this at enterprise scale.
The Scaling Problem Nobody Talked About
Picture a real deployment. You're running an MCP server for millions of users, sitting behind a load balancer whose entire job is to route each request to whatever server in the farm is free — sometimes in a different region, sometimes on a different continent.
Now every one of those machines has to know about a session ID that some other machine handed out.
It's not impossible. But it's a serious pain, and it fights the load balancer instead of working with it. The current setup assumes one server remembers you. Real companies spread traffic across dozens of servers that don't talk to each other by default.
So today's MCP servers have to do extra work just to keep track of who's who. Stateful session management across a distributed fleet is one of those problems that looks trivial until you're the one debugging it at 2 AM on a Saturday.
This has been a significant headache for anyone running an MCP server at scale, and it's part of the reason we haven't seen more companies ship large-scale, first-party MCP integrations despite all the hype around agentic AI this year. The models are ready. The infrastructure isn't.
The Stateless Fix
Under the new system, MCP takes a looser, "stateless" approach to session IDs on the server side. Similar to how most ordinary websites already work — your browser sends a cookie or token with each request, and the server validates it without needing to maintain an in-memory table of active sessions.
The difference is subtle but important. Instead of servers remembering who you are, the session information gets encoded in a way that any server in the fleet can validate independently. No cross-server state synchronization. No distributed session stores to maintain. No cache invalidation nightmares.
This should make the whole system a lot easier to maintain and, in theory, cheaper to run at scale. You can add servers without adding coordination overhead. You can deploy to new regions without replicating session state. The load balancer actually does its job instead of fighting it.
For an SRE team, this is the kind of change that turns a architecture problem into an operational one. And honestly? That's a good problem to have.
Who's Behind This and Why It Matters
The official spec for the new version has been public since May, but we got an unusually clear explanation of the changes from Arcade — a two-year-old startup that's built its entire business around getting AI agents to actually function inside real companies.
They let agents securely connect to and act on tools like Gmail, Slack, and Salesforce. That's not a toy use case. That's the kind of integration that requires production-grade reliability.
Arcade raised $60 million in June based on a specific thesis: most AI agents don't fail because the underlying models are weak. They fail because the infrastructure around them isn't ready yet. This update is trying to address exactly that gap.
The money makes sense when you look at the bottleneck. Everyone's racing on model capabilities. But models are useless if they can't reliably reach the systems they need to operate in. The infrastructure layer — protocols, session management, authentication flows — that's where the real work is happening right now.
The Bigger Picture on Standards Bodies
This is an important reminder that not every part of AI development is moving at breakneck speeds. Model training races ahead. Benchmarks get smashed weekly. But the technical infrastructure those models need is still subject to the slow log-rolling of standards-body consensus.
It really is happening. It's just a little slower.
The gap between what models can do and what they're actually allowed to do in production — that's where protocols like MCP live. And protocol updates don't get shipped on startup roadmaps. They require coordination across vendors, consensus on specs, and enough patience to push through the boring parts.
That's not a criticism. It's just how infrastructure work goes. The companies that figure out how to ship reliable, standards-compliant integrations first will have a real advantage. Not because their models are better, but because they solved the plumbing.