The July 28 spec is the largest revision to the protocol since launch, and the breaking changes are exactly why I’m confident the protocol debate is now over.
Tomorrow the Model Context Protocol (MCP) ships the largest revision to its spec since it launched. The core goes stateless, authorization gets hardened, and extensions become first-class.
Every one of those changes points the same direction. MCP is maturing into infrastructure that enterprises can run in production, and from banks to global retailers, the businesses already building on MCP needed exactly these upgrades. It’s a protocol growing up.
That’s why we’re still betting on MCP, and betting harder.
Full disclosure, we didn’t bet on MCP right away
I’ll confess that we didn’t start as MCP believers.
When MCP first showed up, it was a desktop-only, stateful protocol, and we thought it wouldn’t work for what people were actually trying to build. Most of the agents we saw were cloud-based and multi-user. A stateful, single-machine model was never going to scale to that.
We had already started building our own approach to the problem. But over the following year, many of the ideas we had arrived at independently started to show up in MCP on their own.
That told us two things. One, MCP was becoming the default standard for how agents talk to everything else. And two, everyone building serious agents was hitting the same walls we were, then converging on the same answers.
Going stateless is a clear maturity signal
The headline change in this release is that MCP enshrines stateless requests in its architecture. Any request can now land on any server instance, which means servers can sit behind an ordinary load balancer instead of needing sticky sessions and shared session stores.
The exact stateful design that kept us away early on is the thing this release fixes. It turns out a lot of teams hit that same wall, and the community chose to rebuild the core rather than paper over it.
Protocols that are dying don’t earn that kind of investment.
Why I still tell CEOs to bet on MCP
I get some version of this question every week. Can’t I just use an API? Can’t I just use a command line interface? Usually the person asking that hasn’t shipped a real agent to production yet.
Start with the API question. Yes, models are smart enough to call an API directly. But the moment you build the scaffolding an agent needs to use that API safely, you start rebuilding MCP anyway. You add a semantic layer, you broker delegated user authorization, you handle a dozen things that aren’t obvious until you try to connect them. That’s how all of us ended up here. It was never MCP versus API. It’s MCP as a new kind of API for agents.
CLIs are popular for a narrower reason, and it’s an authorization one. A CLI runs locally, pre-authenticated as you, so a desktop agent sidesteps the multi-user problem entirely. But that agent inherits all of your privileges. It can delete files, drop database tables, and reach systems you never wanted it near. You can’t separate your access from the agent’s. That’s why plenty of large organizations have shut down local CLI-based agents outside of coding. Cloud agents need per-user, per-action authorization, which is exactly what we wrote into the MCP auth spec.
Maturity looks like boring governance
The rest of the release reads like a protocol settling in for the long haul. Authorization now aligns with OAuth 2.0 and OpenID Connect best practices, which makes your security team happier. Extensions become first-class, with their own versioning and release cadence, so the core stays lean while the ecosystem grows. Lesser-used features like Roots, Sampling, and Logging move into a formal deprecation policy with 12-month minimum windows.
None of that is flashy. All of it is what infrastructure meant to last looks like. You don’t publish deprecation timelines for a protocol you expect to abandon. The MCP community is investing in evolving MCP because enterprises are investing in MCP.
The protocol debate is over
My hope is that this is the last time any of us has to explain why MCP is the right approach.
MCP is the definitive protocol by which an agent talks to anything, and it’s become dominant enough that it’s very close to the only one that matters. The models are already smart enough for almost everything you want to build.
APIs get consumed by MCP. Skills pair with MCP. CLIs stay niche and mostly coding-bound. A2A has genuinely interesting ideas, and I’m curious to watch it and MCP converge under the same Linux Foundation umbrella, but it isn’t anywhere near MCP’s footprint in production.
That’s the bet. A protocol that keeps orienting itself around what production teams actually need is one worth building on.
At Arcade.dev, our job is to absorb the complexity these changes create. Our runtime supports both the old and new protocol versions, so you don’t have to care what your client speaks, and we help write the spec rather than just react to it.
This release is proof the bet was right. Now we get to keep making it.
From explainers to step-by-step instructions, Arcade is your guide to the largest revision to the MCP spec since launch. Click here for all of our coverage.
