The biggest MCP upgrade yet makes MCP harder to depend on

Every write-up of the new Model Context Protocol spec says the same thing: MCP is growing up. They point to the stateless core, the hardened auth, and the first formal deprecation policy. The protocol question, which protocol wins for connecting agents to tools and data, is now treated as settled.

It isn’t. We run MCP servers in production and govern them for teams that run their own, so this release isn’t abstract to me. The update is good. It also makes MCP harder to depend on in the near term. Both are true, and the second is the part worth your time.

The stateless core is the real improvement

It lets you put MCP servers behind a normal load balancer instead of pinning every client to the instance that opened its session. The maintainers are also trying to end the run of breaking releases that got MCP here. The protocol now sits under the Linux Foundation’s Agentic AI Foundation, and the new policy keeps a deprecated feature in the spec for at least twelve months before removal. That is the right direction, because a shared standard only works if it holds still long enough to build on.

MCP is not replacing the API

The reaction, though, has run ahead of what shipped. For a year the pitch was that agents would talk to MCP, MCP would talk to everything, and APIs would fade out. That was never right, and this release doesn’t make it right. MCP is a good way for a model to find a tool and call it. Underneath every one of those calls is still an API doing the work, hitting the system of record, enforcing the permissions. Putting an MCP server in front of Salesforce doesn’t stop Salesforce being an API. MCP sits on top of what is already there.

The fragmentation gets worse

MCP is already fragmented, because it keeps changing how it works. This is the biggest change yet, and it splits the field again between the clients and servers that moved and the ones that didn’t.

The fallback is handled well. A new client drops to the old handshake when it meets a server still on the last version, so nothing breaks outright. But dropping down means old behavior. The stateless model, the hardened auth, and the redesigned task lifecycle only work where both ends have upgraded.

So what you can rely on across your estate is whatever your least-updated server supports. Tens of thousands of MCP servers are already out there on older versions. You don’t control the servers you didn’t build, and while the old versions keep working, their owners have little reason to rush. The bigger the change, the longer they lag, and the longer you run the old protocol no matter what your newest client can do.

Govern the boundary

Your teams are already using MCP. The question is how you build on something that keeps changing shape. The parts you depend on have to survive the next version, and there will be one. Your integrations, your access controls, and the log of what your agents did and were cleared to do can’t be work you redo every time the spec moves.

So don’t wire agents straight to the protocol. Put a layer you control in between, where access, approval, and logging are set once and hold no matter which version a server speaks. When MCP changes again, that layer takes the hit and your architecture doesn’t. Same when the next standard arrives. Google’s Agent-to-Agent protocol is already coming.

That’s what Agent Gateway is, and why we built it to handle more than one protocol. The principle holds either way. Govern the boundary. The protocol won’t stand still, and this release is the proof.