As the person who owns MCP operations at Barndoor AI, I’ve spent the last couple of years building, running, and debugging MCP server implementations at scale, watching the spec evolve through every major revision along the way. Here’s my read on the July 28, 2026 MCP release candidate and what it means keeping MCP running in your org.

What’s Changing in the MCP July 2026 Spec (And Why It Matters)

MCP’s roots are in the Language Server Protocol: stateful, bidirectional, built for one IDE talking to one language server on a developer’s machine. That model works great locally. It gets expensive fast once you’re running remote MCP servers serving many clients at once, you end up needing sticky routing and shared session stores just to keep track of who’s talking to whom. This exact scaling pain has been a topic across the MCP community, and it’s the headline change in this release: MCP drops the implicit session model and moves to stateless request/response by default, the same shift the web made with REST years ago.

But the stateless shift is really a symptom of a bigger story, and that’s why this release matters more broadly than any single change in it. MCP is outgrowing its origins as a developer’s-desktop tool and becoming infrastructure that has to hold up at cloud scale, for whoever’s running it and whoever’s connecting to it. That shows up in how this spec handles identity, Dynamic Client Registration is being phased out in favor of a stronger model. It shows up in governance, a new subscription mechanism now lets servers signal changes instead of breaking clients silently. The four changes below are where that all lands in practice.

4 Key MCP Spec Changes 

  1. Stateless Sessions: If your server or agent needs to track state across calls, that now has to be explicit, an identifier passed as a regular parameter, part of your own domain model rather than something the protocol hands you. Here’s a concrete case where this matters: imagine an agent working through a large codebase migration, it opens a project once, and every subsequent tool call (run tests, apply a patch, check a file) needs to act on that same open working copy rather than reloading gigabytes of context each time. Under the old model, the session ID handled that invisibly. Now the server has to hand back an explicit handle, something like a workspace_id, and the agent passes it on every call. More visible, more deliberate, and honestly easier to reason about once it’s built.
  2. Session IDs: Session ID becomes something you own. Most simple, RESTful-style MCP servers won’t feel this at all, everything they need already arrives as parameters. But if you’ve built anything that leans on implicit session state, conversational agents, multi-step workflows, that dependency needs an explicit replacement now. Better to find that out on a test server than to discover which of your integrations quietly assumed a session existed after something breaks in production.
  3. Identity is getting a real overhaul. DCR (Dynamic Client Registration) is being phased out in favor of CIMD (Client ID Metadata Document). Most large providers skip the security provisions that would make DCR safe, things like initial access tokens or software statements, which leaves DCR wide open in practice. CIMD sidesteps that gap entirely with a fundamentally more secure model. Instead of registering your client with every server you connect to, you just present a URL pointing to a document hosted on a domain you own. That document is your identity. The server fetches and validates it, confirms you are who you say you are, and you’re in, no registration handshake required. It’s a lot like a callback: don’t call us, we’ll call you. It’s also a meaningfully harder thing to fake than open-ended DCR, since spoofing it means compromising a domain you control, not just submitting a form. Most implementations today still run on DCR, but if your identity team already has opinions about how OAuth and OIDC should work, expect those opinions to matter more for MCP going forward. We support CIMD at Barndoor.
  4. Change Management: There’s a new subscription mechanism for change management. Servers can now notify clients when their tool list, prompts, or resources change, instead of clients finding out the hard way. This lands directly on a real pain point in the community, a recurring topic at the MCP Dev Summit and across the MCP Discord, where consumers routinely struggle when a server they didn’t author changes out from under them with no warning. Read less as “something’s about to break” and more as a signal that hygiene around communicating changes is becoming a first-class concern for the protocol, not an afterthought.

How to Prepare for the MCP Spec Change

  • Test against the new spec now. Spin up a server running the new version and run your existing agents against it. You’ll find out what breaks on your terms, not a provider’s.
  • Take stock of where you actually rely on MCP session ID. 
  • Check what version the servers you depend on are running. server/discover is your early-warning system: call it to see which protocol versions a server advertises before it surprises you in production. New-spec servers answer it directly; older servers won’t recognize the method, which is itself your signal to treat them as pre-July-28 and fall back to the old initialize handshake for those. This is also where a gateway earns its keep. Probe each server once, cache the advertised versions centrally, and turn version tracking into a lookup instead of a per-connection handshake.
  • If you’re still on DCR, check whether CIMD is already available to you. It may be built into your stack and simply not turned on yet, that was true for us internally before we caught it. 

How a Centralized MCP Gateway Handles Spec Changes for You

This won’t be the last time MCP’s spec shifts under you. Sessions, DCR, whatever comes next, if you’re managing MCP servers one by one, every future change means re-checking each one individually.

That’s exactly the complexity an MCP gateway is built to absorb: every server sits behind one connection point, so spec versions get tracked in one place instead of chased down server by server. If you’re considering a gateway to manage this centrally, the 2026 MCP Gateway Buyer’s Guide walks through what to evaluate.

Barndoor MCP Governance is built on that same principle, and takes it further. Beyond absorbing protocol and spec version differences, it gives you centralized visibility, access control, and an audit trail across every MCP server your org connects to. A spec change like this one becomes one more thing handled at that layer, not a separate fire drill for every server you depend on. Request a demo or start a free trial to see it in action.