MCP Specification 2026-07-28: What the Authorization Hardening and DCR Deprecation Mean for Your Integrations

The Model Context Protocol maintainers finalized the 2026-07-28 specification on that date, and their own release notes call it the most substantial revision to the protocol since authorization was added to MCP in the first place. The changes fall into two groups: architecture changes that make an MCP server easier to run at scale behind ordinary infrastructure, and authorization hardening that changes how a client is expected to register and authenticate. Both groups matter for anyone who has already shipped an MCP server or client, because several of the changes are not additive, they retire a pattern the spec previously endorsed.

Why the stateless core is the change to prioritize first

Before this revision, a remote MCP server that needed to scale typically needed sticky sessions, a shared session store, and often deep packet inspection at the gateway just to keep a client's session state consistent across requests. That is real infrastructure overhead for what is fundamentally a tool calling protocol, and it pushed teams toward heavier deployment patterns than the workload actually required. Under the stateless core, that same server can run behind a plain round robin load balancer, route requests using the new Mcp Method header, and let clients cache tools/list responses instead of refetching the tool catalog on every session. For a team running an MCP server behind Cloud Run or a Kubernetes ingress, this is the change that actually reduces operational complexity rather than just adding a capability, and it is worth revisiting your deployment topology specifically to remove infrastructure you no longer need rather than leaving the sticky session workaround in place indefinitely.

The DCR deprecation is the one that needs a migration plan

Dynamic Client Registration let an MCP client register itself with a server at connection time without a human provisioning credentials in advance, which was convenient but also the part of the spec that made client identity hardest to audit. The 2026-07-28 spec formally deprecates DCR in favor of Client ID Metadata Documents, a model where a client's identity is described by a metadata document the server can fetch and verify rather than a registration request the client makes on the fly. DCR continues to function for backward compatibility today, but the spec is explicit that it will be removed in a future version, which means any integration currently relying on DCR for client onboarding has a real deadline to plan around, not just a recommendation to eventually get to. Combined with the other authorization hardening in this release, issuer validation and issuer bound client credentials, the direction is consistent: MCP is moving away from patterns that were easy to stand up quickly and toward patterns that are easier to audit in an enterprise identity model. We covered the broader shift toward agent identity and OAuth patterns for MCP in MCP authorization, agent identity, and OAuth for the enterprise, and this release is the concrete specification change that argument was anticipating.

What this means if you are integrating against a first party MCP surface

Several vendors have shipped first party MCP servers this year rather than leaving integration entirely to third parties, and the access control discipline this spec update pushes toward applies just as much to consuming one of those as to building your own. We wrote about this directly for NetSuite's AI Connector Service and its MCP Standard Tools SuiteApp: the governance question was never really about whether MCP is enabled, it was about which scope and which permissions the connecting client actually carries. The 2026-07-28 spec's authorization hardening gives that governance question a more precise vocabulary, issuer bound credentials and verifiable client metadata documents instead of an opaque dynamically registered client, but it does not remove the underlying obligation to scope access deliberately. The same applies on the commerce side to a conversational storefront integration like the one we detailed in Shopify's Storefront MCP for in store AI agent cart and checkout, where the client connecting to your storefront's MCP surface should be verifiable under the new model rather than trusted on the strength of a registration request alone.

What to actually do this quarter

Audit any MCP server you run for session state assumptions baked into your load balancer or gateway configuration, since the stateless core is a genuine simplification opportunity, not just a compliance checkbox. Separately, audit any MCP client you operate for reliance on Dynamic Client Registration, and if you find it, start planning the move to CIMD now rather than after DCR support is actually pulled from a future spec revision. Neither of these is an emergency this week, but both are the kind of infrastructure debt that is much cheaper to retire on your own schedule than on the protocol maintainers' removal timeline.

FAQ

What is the biggest change in the MCP 2026-07-28 specification? The maintainers describe the stateless protocol core, which removes the need for sticky sessions and a shared session store behind a load balancer, as the most substantial architecture change, alongside formal deprecation of Dynamic Client Registration.

Is Dynamic Client Registration removed already? No. DCR still works for backward compatibility, but it is formally deprecated in favor of Client ID Metadata Documents and is planned for removal in a future version of the spec.

Do I need to migrate Roots, Sampling, or Logging immediately? No. Those are deprecated but guaranteed to keep working for at least twelve months. New implementations should avoid adopting them, but existing ones have a real window to migrate.

Does this change how I should deploy an MCP server? Yes, for the better. The stateless core lets a server run behind ordinary round robin load balancing and header based routing instead of sticky sessions, which is worth revisiting even if nothing else about your integration changes.

When this applies to your stack

If you are running or planning an MCP integration, whether that is your own server exposing internal tools to Claude or another client, or a client connecting to a vendor's first party MCP surface, this specification revision is the concrete update to check your architecture and your client authentication against. Scoping that access correctly and migrating off deprecated patterns like DCR before they are removed is the kind of API integration and infrastructure work we do at Contra Collective.