Table of Contents
Don't have the time to read the entire post? Our human writers will be sad, but we understand. Summarize the post with your preferred LLM here instead.
The Model Context Protocol (MCP) recently published its latest specification revision, and it’s the biggest set of changes since the June 2025 authorization overhaul. It’s also the first to ship breaking changes, which include stateless transport, the removal of initialization handshakes, and a set of deprecations governed by a new lifecycle policy.
There are two main “categories” of changes, with different levels of impact:
How MCP communicates is the biggest change
How MCP handles authorization remains mostly the same, with additive changes that formalize what mature authorization servers and resource servers were already doing
Our analysis will cover both sides of that equation, but with most of our attention on the second category: the six authorization SEPs, the two deprecations with credential implications, and Enterprise-Managed Authorization (EMA) appearing in an official spec revision for the first time.
If you need a refresher on MCP fundamentals, start with our overview of the protocol and our deep-dive with the auth spec.
What changes in the July 2026 MCP revision, at a glance
The release candidate announced in May covers the full changelog, and the specification should be considered the source of truth for anything wanting a more granular discussion. Here’s the short version:
Change | What it replaces | Is it breaking? |
|---|---|---|
Stateless HTTP transport | Sessions and the Mcp-Session-Id header | Yes |
Capability discovery via server/discover and per-request _meta | The initialize/initialized handshake | Yes |
Server-initiated requests only during active client requests | Long-lived streams with out-of-band server messages | Yes |
Multi Round-Trip Requests (MRTR) | Server-initiated requests over a held-open stream | Yes |
Roots, Sampling, and Logging deprecated | Still functional because removal requires a future SEP and at least 12 months | No |
Six authorization SEPs | Informal or implementation-specific behavior | No |
EMA, MCP Apps, and Tasks are official extensions | Extensions living alongside the spec with no defined place in it | No |
Tasks as the io.modelcontextprotocol/tasks extension | Tasks in the experimental core | No |
The headline change on the transport side is statelessness, and the reason is operational rather than security posture. Sessions made MCP servers hard to load balance, a pain to run serverless, and cumbersome to scale horizontally. They were also fragile. A server restart or a dropped connection could lose the session ID on either side, and the client had to start over. Removing the session fixes all of that.
Where MCP going stateless touches identity
If your MCP deployment follows the existing authorization spec as written, then statelessness changes basically nothing about your auth. The spec has treated MCP servers as OAuth resource servers since June 2025. A separate authorization server issues tokens, and the MCP server validates what each request carries.
Where sessions did touch identity was in the work the spec asked you to do around them. Its previous guidance on session hijacking told servers to key session state as <user_id>:<session_id>, with the user ID derived from the verified token rather than supplied by the client. Guess a session ID and you still couldn't act as someone else.
That rule survived the transition nearly word for word. The new section on state handle hijacking asks servers to key stored state as <user_id>:<handle> on identical reasoning, and it states the principle more bluntly: servers MUST NOT treat possession of a state handle as authentication.
What changed is which layer owns the identifier. The transport minted the session ID and carried it in Mcp-Session-Id, which put it in the spec's surface area where implementers were already looking. A state handle is a shopping cart ID or a workflow ID that your own server invents and takes back as an ordinary tool argument. It looks like a business object, not a credential. Statelessness didn't remove the hijacking risk, it relocated it into code nobody thinks to threat-model.
The revision pulls in the other direction elsewhere. Servers may now issue requests to the client, like elicitation, only while actively processing a client request. That was a recommendation before and it's a requirement now. Every prompt a user sees traces back to something they started, which closes an out-of-band phishing vector that used to depend on client behavior. The same redesign also changes how servers hand users off to third-party authorization.
How third-party OAuth flows change under MRTR
Elicitation is how an MCP server asks a user for something mid-tool-call, and URL mode is how it hands them off to an authorization flow. A tool finds it has no credentials for a third-party API, returns a URL-mode elicitation pointing at that provider's /authorize endpoint, and waits for the user to come back.
Under the MCP spec revision 2025-11-25, that handoff had two protocol-supplied parts. The request carried an elicitationId for correlating the out-of-band interaction, and the server pushed notifications/elicitation/complete when the flow finished. Multi Round-Trip Requests (MRTR) removes both, because neither survives without a held-open connection. The server now returns resultType: "input_required" along with what it needs and an opaque requestState blob, and the client retries the original call with the answers and that blob echoed back.
The elicitationId removal is the one to look at. It was a correlation identifier, and the C# and Go SDK docs both show the obvious shortcut of passing it straight into the authorization URL as the OAuth state parameter. That worked. It also meant a CSRF defense was riding on a field the protocol happened to supply. Now your server mints its own state, stores it against the verified user, and checks it at the callback like any other OAuth client.
There's a second identifier riding along in this flow. requestState carries a partially completed authorization across a retry, and that retry can land on any instance in your fleet. Entropy isn't the whole problem. If you encode state into it rather than using it as a lookup key, anyone who can edit it can rewrite the terms of an in-flight authorization, so it needs integrity protection too.
The elicitationId removal is the same pattern as the session ID, one layer up. The protocol stopped handing you an identifier, and the security property it was carrying is now yours to keep.
How the auth SEPs describe a real authorization server
There are six auth SEPs in this revision, and none of them introduce a novel security idea. That’s to their credit, though; they take judgment calls that were previously left to implementers and assign them to the authorization server, which is what the MCP authorization spec has always done at its best.
The spec remains deliberately minimal in spite of this new enumeration, defining what the authorization server must expose and staying silent on how you deliver it.
SEP-2468 requires clients to validate the issuer identifier (iss) on authorization responses per RFC 9207. This is a low-cost migration for a class of attacks that MCP’s single-client, many-server deployment style makes quite relevant because one client can hold relationships with dozens of authorization servers at once. A future version will expect clients to reject responses that omit iss, so authorization servers should begin supplying it now (if they don’t already)
SEP-837 has clients declare their OpenID Connect (OIDC) application_type (web or native) during registration. It’s a rather small change that fixes a recurring failure where an authorization server assumes an unknown client is a web app and rejects its localhost redirect. This also gives the authorization server one more signal to use in registration policy.
SEP-2352 binds registered client credentials to the authorization server that issued them. If an MCP server migrates to a different authorization server, clients register again rather than carrying credentials across. This follows directly from issuer validation, so a credential that outlives its issuer relationship can’t be validated coherently.
SEP-2207 standardizes how clients request fresh tokens from OIDC-style authorization servers using the offline_access scope. This is a pretty minor bugfix that simply corrects an issue with MCP client not getting refresh tokens.
SEP-2350 clarifies scope step-up. When a server signals that it needs additional scopes, the client computes the union of existing and newly required scopes, and requests that. The accumulation burden moves off the server. We’ve already covered the step-up pattern in greater depth in our progressive scoping post, where you can learn more about this mechanism.
SEP-2351 clarifies /.well-known/oauth-authorization-server discovery. There’s not much to say on this one other than “support it.”
None of these are net-new changes. If your MCP auth setup was already mature and playing by the best practices, these are configuration checks rather than migration steps.
One authorization change in this revision isn't a configuration check. Dynamic Client Registration (DCR) is now formally deprecated in favor of Client ID Metadata Documents (CIMD). DCR keeps working for backward compatibility and comes out in a future version, so the twelve-month lifecycle policy applies. The direction is set, and it changes what a client identity is. Under DCR, the authorization server mints a client_id. Under CIMD, the client_id is a URL that the authorization server fetches to read a metadata document. Identity comes from control of a domain instead of from a registration record.
That fits MCP's many-server deployment pattern better, and it hands your authorization server a decision it didn't have before: which domains do you accept a client ID from?
That's one server deciding which clients it trusts. EMA is the same class of question at organizational scale, and it's the identity headline of this revision. Enterprise rollouts have been hitting it since MCP's first release: when hundreds of employees connect MCP clients to dozens of MCP servers, who governs that?
Enterprise-Managed Authorization answers the governance question
While stateless was the star shakeup for transport, Enterprise-Managed Authorization (EMA) is the identity headline of this revision. EMA answers a quest enterprise rollouts of MCP have been hitting since its first release: When hundreds of employees connect MCP clients to dozens of MCP servers, who governs that?
The default answer has been consent sprawl. Each user approves each client against each server, admins have no central view of the grants, and revocation means chasing them down one at a time.
EMA replaces that with the trust relationship enterprises already run. It’s built on Cross-App Access (XAA), which uses the Identity Assertion JWT Authorization Grant (ID-JAG), an IETF draft extending OAuth token exchange.
Here’s the flow in a compressed format:
A user signs in to their MCP client single sign-on using an enterprise identity provider (IdP), as they already do.
When the client needs access to an MCP server, it asks the enterprise IdP (Okta, Microsoft Entra, and so on) instead of starting a consent tango with the server.
The IdP applies the admin’s policy and issues a signed identity assertion (the ID-JAG).
The MCP server’s authorization server validates the assertion and issues its own scoped tokens, exactly as it would after an interactive flow.
The authorization decision moves to the enterprise IdP, where admins already manage every other application. Users stop seeing consent screens for connections their admin has approved. Admins get one place to grant, scope, and revoke agent access across the organization. And because the resource’s authorization server still mints its own tokens, nothing about downstream token validation changes.
EMA has been an extension for months, and there's already a production rollout to learn from. Atlassian’s blog discussing their EMA rollout provides a solid blueprint. The extensions framework gives it a defined place to live, which matters more than it sounds. Extensions evolve on their own schedule instead of waiting on an eight-month spec cycle, so EMA can move faster than the core protocol does.
Descope’s Agentic Identity Hub both issues and validates ID-JAGs, so a Descope-protected MCP server accepts EMA connections from enterprise customers’ own IdP with no additional consent flow, and SSO groups map to roles and policies that decide which scopes each user’s agents receive, per tenant. For more on where this lands in the realm of gateway architectures, see our developer guide to MCP gateways. You can learn more about the underlying standard in our XAA/ID-JAG explainer.
How MCP Apps support agent readiness
MCP Apps is the other extension the revision names. Servers can now deliver interactive UIs inside AI clients, which matters most in cases where a list of JSON fields is a bad answer. Commerce is the clearest one. A product grid or a checkout confirmation is something a user needs to see and act on, not read back as text.
Rendering the UI is the easy half. The harder question is who the agent is acting for when the user clicks buy. A checkout surface drawn by your server inside someone else's client still has to know that the cart belongs to a verified user and that the payment method on file is theirs. That's identity linking, and it's what separates a demo from something you can put in front of customers.
It also inherits the question URL-mode elicitation was designed around. The reason sensitive input goes out to a URL is that the user can see where they are and verify what they're authorizing. MCP Apps puts server-authored UI back inside the client. Anything in that UI that collects a secret or commits a payment deserves the same scrutiny.
The Descope Peek-A-Box demo showcases the sample MCP server from our guide, Build an Ecommerce UCP Server With Identity Linking. In the tutorial, we explain what the Universal Commerce Protocol (UCP) is, why identity matters in agentic commerce, and what you can build once an agent's session is connected to a verified user.
You can also explore the Peek–A-Box sample app code on our GitHub, the MCP server component of which is built with FastMCP and Descope. This working UCP implementation includes a UI rendered with MCP APPs, a catalog, checkout, and orders.
What’s deprecated in this MCP spec revision
Roots, Sampling, and Logging are deprecated but functional. The revision also introduces a lifecycle policy: removing a deprecated feature requires its own SEP and at least 12 months from the deprecation date. Nothing here is a fire to put out, yet, and spec-tracking content and code receive a predictable cadence for it.
There’s one deprecation that has credential implications. Sampling previously would let an MCP server request LLM completions through the client, borrowing the client’s model access. Its replacement is direct integration with LLM provider APIs, which means servers now hold their own provider credentials. That’s a new class of downstream secret to store, rotate, and revoke, and it belongs in a managed credential vault like Descope Connections rather than in environment variables.
The replacement for Roots isn’t as significant, but it still places a judgement call back on the operator: resource boundaries move from client-declared to server configuration.
What to do before your next MCP deployment
There’s a migration in store from this revision, but it’s pretty well-bounded. Now that the new spec is final, check for these four things:
Any code reading
Mcp-Session-Idor holding session stateAny logic built on long-lived streams
Whether your MCP auth setup handles the six SEPs above (most mature ones already do)
Which spec you’re looking at, since the
/draft/URL has moved to/specification/2026-07-28/at publish
If you’re selling to enterprises, add a fifth box to tick: EMA support is going to be the new expectation.
The revision’s direction is reassuringly consistent with everything we’ve seen in terms of developer sentiment and best practices since June 2025. The protocol keeps getting simpler about transport (which is good) and more explicit that trust decisions belong to the identity layer (which is even better). We’d expect that trajectory to continue as MCP matures.
The Agentic Identity Hub is built to absorb exactly this kind of release. The new authorization requirements are arriving as settings to plug in, not code to write, and Descope already embodies the principles that underlie the auth SEPs here.
To see how Descope can support the new spec, sign up for a Free Forever account, explore the Agentic Identity Hub, or bring questions to AuthTown, our developer community. Looking to secure an agentic project, or make your APIs agent-ready? Book a demo to chat with our auth experts.
