.png)
The latest MCP specification changes more than the way clients and servers connect. It changes how the protocol can evolve, how enterprise authorization fits into the stack, and what it means to build agents that operate across applications.
At our recent "What's up with MCP?" panel with Okta and MCPJam, we covered many of these changes live—and the audience raised plenty more questions than we could get to.
We pulled together the questions that deserved a deeper answer, from the move to stateless MCP and richer JSON Schema support to Cross-App Access, ID-JAG, agent identity, credential management, governance, and guardrails.
Here's what we think matters most.
Slower—and that's a good sign.
The July 28, 2026 release made several significant changes: it removed protocol-level sessions, made the handshake stateless, moved tool schemas to full JSON Schema 2020-12, and strengthened the authorization flow.
Changes like these are expensive for an ecosystem to absorb. You don't want a protocol making foundational changes every few months.
The more important change may be what the release makes possible next: extensions can add new capabilities without changing the core protocol.
Enterprise-Managed Authorization is already an example. It moved from proposal to stable in June 2026 through the extension model, without requiring changes to core MCP.
That suggests the next phase of MCP may be less about repeatedly changing the foundation and more about capabilities evolving independently around it.
For a maturing protocol, that's a healthy direction.
Not quite.
Both content and structuredContent remain in the July 28 specification, and content is still required for backwards compatibility.
When a server returns structured data, it therefore has to provide it in both places:
The ecosystem hasn't completely settled on how these fields should behave in practice, either. We've seen client-side issues where content gets dropped once structuredContent is present, as well as implementations that return only structuredContent and break clients expecting the required duplicate.
A useful mental model is: content is for the model. structuredContent is for everything that needs to consume the result afterward.
The protocol supports both because the ecosystem is still transitioning.
As for anyOf and oneOf: that change has landed.
The July 28 release expanded inputSchema and outputSchema to the full JSON Schema 2020-12 keyword set, including anyOf, oneOf, allOf, conditionals, $ref, and $defs.
There are still guardrails. inputSchema must have an object at the root, external $ref URIs can't simply be followed without restriction, and implementations need to bound schema nesting.
So this isn't arbitrary JSON Schema with no constraints. It's substantially richer schema support with boundaries designed for implementations to remain safe and predictable.
MCP Apps is an important next step because it moves MCP beyond tool calls and text into interactive experiences.
Adoption is still early, but the direction is significant: a product can bring more of its experience into the MCP client a user is already working in, rather than asking that user to leave and return to the original application.
That's powerful for users. It also creates a strategic question for vendors:
There is a familiar precedent here. Alexa Skills and Facebook Messenger bots gave brands distribution inside someone else's ecosystem, but companies that moved their entire interactive experience into those platforms also gave up significant control over the customer relationship.
MCP is different in an important way: it is a multi-vendor open protocol, so there isn't a single company that can unilaterally shut down the ecosystem. But individual MCP clients still control discovery and ranking within their own surfaces.
The practical trade-off is relatively straightforward:
The strategic question for vendors is which parts of the experience belong inside the agent and which parts should remain your own surface.
It doesn't need to be.
Cross-App Access already fits into the extension model. MCP authorization extensions are optional and additive, and can evolve independently from core behavior.
XAA and ID-JAG live in that model as part of Enterprise-Managed Authorization. The extension became stable in June 2026 without requiring changes to MCP core.
Core MCP authorization already covers significant parts of the OAuth model, including OAuth 2.1, PKCE, resource indicators, issuer validation, step-up scopes, and client registration.
What it doesn't attempt to make universal is enterprise SSO and zero-touch consent.
That's intentional. Those capabilities are useful for some environments but aren't requirements for every MCP deployment. Extensions let enterprise-specific capabilities evolve without forcing them onto implementations that don't need them.
How does ID-JAG fit into this?
ID-JAG is a JWT authorization grant that plugs into the standard OAuth token endpoint. It's an OAuth extension, not a separate authorization system.
The important distinction is that the identity provider and the MCP server's authorization server still have different responsibilities. The IdP can assert the user's identity and relevant policy, but the MCP server's authorization server ultimately validates that assertion and mints its own scoped token.
That separation becomes important as agent-to-application access becomes more common.
The basic problem isn't new.
Cross-App Access was designed around one application calling another on behalf of a user. An agent acting for that user has the same fundamental shape.
What changes is the scale and behavior.
A human may interact with a handful of applications throughout the day. An agent can invoke the same grants hundreds of times a minute across tools the human never directly touched.
That means workforce identity policies can't stop at questions like: Who is this user, and what scope do they have?
They increasingly need to reason about how an agent is behaving: call volume, patterns, downstream tools, and whether activity is consistent with what the user actually intended.
Extending workforce identity to agents is therefore less about pointing the existing identity system at a new client type and more about expanding what the policy model can express.
XAA depends on an enterprise identity provider to anchor trust.
Outside that environment—an individual developer, a small team, or a consumer-facing agent—there may be no enterprise IdP to make that assertion.
The problem becomes credential management rather than identity federation.
A useful model is a centralized vault that holds the credentials an agent needs, handles the OAuth flows for individual services, and rotates credentials without requiring the agent or developer to handle raw secrets.
The underlying principle is similar: don't scatter credentials across every agent and tool.
The difference is that there isn't an enterprise identity provider providing the trust anchor.
Once agents become first-class actors alongside humans and services, access management becomes much more dynamic.
An agent identity can be provisioned and torn down far more frequently than a human employee. That means "who has access to what?" increasingly needs to be a live question rather than something answered only during periodic access reviews.
Audit trails also need to evolve. A human access log might tell you that someone logged in and interacted with an application. An agent access log needs to help answer a different question: Which actions were actually triggered by the user, and which did the agent decide to take on its own?
That distinction becomes critical as agents gain more autonomy.
The IdP and the application's authorization server are often separate systems.
For example, Okta can establish who a user is, while Slack's own authorization server determines what that user or client can actually access and issues the corresponding token.
In a traditional OAuth flow, the user may see an explicit consent screen: This application wants access. Allow?
With enterprise SSO and zero-touch consent, that decision doesn't disappear. It moves. Instead of being made by the user at request time, it can be established ahead of time through administrator-configured policy at the IdP.
An administrator can define that a particular group is allowed to use a given agent against a given application with a particular scope. When the request happens, the IdP checks that policy and provides the assertion rather than asking the user to make the same decision again.
No consent popup doesn't mean no consent. It means the consent decision happened earlier, at a different layer.
Yes.
When there is no user involved and an agent is acting independently, Client Credentials is the appropriate grant, and it should not carry a refresh token.
The reason is straightforward: the client can authenticate again with its own credentials when it needs a new access token. A refresh token would simply provide another way to accomplish the same thing.
When the agent is acting on behalf of a user, token exchange is the appropriate pattern.
The resulting token remains connected to the user's identity, with the original user represented by sub and the acting agent represented by act.
The same principle applies to refresh tokens. A delegated token can be obtained again through another exchange, so a separate refresh mechanism is generally unnecessary.
One important distinction is that a delegated token is tied to the token lineage, not the user's live browser session.
If the credential being exchanged remains refreshable, delegated access can continue after the original browser session ends.
What survives is the token lineage—not the browser session.
The important distinction isn't whether the caller is an MCP client. It's whether the caller is acting on behalf of a user.
An MCP client is simply an OAuth client that happens to communicate using MCP. The authorization code flow doesn't change because the software happens to be an MCP client.
If an application is acting on behalf of a user against an MCP server, it follows the same underlying authorization model. If there is no user involved, it's machine-to-machine access, which is where Client Credentials applies.
No.
MCP's scope mechanism supports per-operation granularity. A server can define scopes for individual tools or groups of tools, and a client can receive only the capabilities it requests and is authorized to use.
Additional access can be requested through step-up mechanisms where appropriate.
If an implementation feels all-or-nothing, that is often an implementation limitation rather than a protocol limitation. A server may simply validate whether the token has any valid scope for that server rather than checking which specific operation the scope permits.
Because the IdP and MCP server answer different questions.
The IdP determines whether an identity can use an application at all. That's the coarse-grained policy layer.
The MCP server knows what the application actually exposes.
It knows that a Slack MCP server might have a send_message tool and a read_channel_history tool, and those capabilities may need different authorization.
The resource server therefore needs to remain the source of truth for the capabilities it exposes.
The IdP can help govern which identities can access those capabilities, but it can't invent the application's capability model.
An id_token represents a login event. It has a short validity window and doesn't renew itself.
An access_token, by contrast, is the credential a client actually continues to hold while it is valid. A refresh token can be used to obtain a new access token when necessary.
That makes the access token the more practical credential to present when returning to the IdP for a downstream exchange such as requesting an ID-JAG.
A simple way to think about the distinction:
An id_token tells you who logged in. An access_token is what you use while acting on that authorization.
Yes.
An MCP server or gateway becomes an XAA client when it needs to make an upstream call to another XAA-enabled application.
The same on-behalf-of pattern applies: the intermediary exchanges a token for the next hop rather than creating a flat service credential. The user's identity remains represented in the act claim.
There are two architectures worth distinguishing.
In both cases, the principle is the same: each hop should obtain authorization for the next hop rather than flattening the entire chain into one service identity.
An MCP gateway can therefore authenticate users through the IdP directly and then follow the same per-hop exchange model downstream.
Discovery and governance are related but different problems.
Finding every shadow MCP server in an enterprise is an asset inventory problem. Identity and authorization don't magically solve discovery.
But governance doesn't necessarily require perfect inventory.
If every legitimate path to company data requires an IdP-governed, admin-approved credential, an unapproved MCP server can exist without automatically gaining access to protected resources.
It still can't obtain a usable, appropriately scoped credential through the governed path.
That shifts the problem from: "Can we find every MCP server?" to: "Can an unmanaged MCP server access anything valuable without going through our authorization controls?"
Network and endpoint controls still have an important role. Egress allowlisting and endpoint detection can help identify unknown MCP configurations and network activity.
But they can't be the entire strategy. A developer running an unvetted server locally inside an IDE may never pass through a network gateway.
Identity-governed issuance provides another layer of control: access to protected resources depends on having the right identity, policy, and scoped credentials. For a deeper look at MCP security risks in the enterprise, the patterns extend well beyond shadow servers.
It depends on how stable the workflow is.
Imagine a workflow where the sequence never changes:
If that sequence is stable and well understood, turning it into a composite tool can make sense.
The model gets one well-defined action instead of having to orchestrate several tools correctly every time. That can improve reliability, reduce token usage, and eliminate opportunities for the model to skip or misinterpret a step.
But composition has costs.
A composite tool is less flexible when the workflow changes, and it can hide failures. If something breaks three steps into the workflow, the outer agent may see only "tool failed" rather than being able to inspect each individual call.
So the trade-off is: Composite tools optimize for reliability and cost. Direct orchestration optimizes for flexibility and visibility.
For stable, high-frequency workflows, composition can be a strong fit.
For evolving workflows—or situations where you need detailed visibility into failures—letting the model orchestrate the individual steps may be preferable.
Start by separating guardrails into two categories.
That distinction should determine where you use them.
For irreversible or high-consequence actions, deterministic controls should sit on the critical path. If the downside is sensitive data leaving the organization or a destructive action being executed, a probabilistic check isn't enough on its own.
Non-deterministic controls are better suited to fuzzy boundaries: tone, relevance, intent, or whether a request makes sense.
The simplest rule is: Use probabilistic controls for ambiguity. Use deterministic controls for consequences.
The ecosystem is still early, but support is growing.
The draft identifies Asana, Atlassian, Slack, Figma, Linear, Canva, and Supabase as supporting ID-JAG, and notes firsthand experience with PostHog.
The broader direction is clear: as the standard matures, more application vendors will need to support ID-JAG-style token exchange if Cross-App Access is going to work consistently across the enterprise application ecosystem.
The latest MCP changes are less about adding another feature and more about establishing a foundation that can evolve without constantly breaking the ecosystem.
Statelessness simplifies the protocol. Richer schemas make tools more expressive. Extensions create room for capabilities such as Enterprise-Managed Authorization to evolve independently of core.
But the bigger challenge is now moving up the stack.
As agents gain the ability to act across applications, identity, authorization, credential management, governance, and fine-grained access control all become more important.
That's the question we're digging into next: how should access control for agents differ from the access control we've built for humans?
We'll explore that in the next post. For a head start, access control for multi-tenant AI agents already surfaces many of the same tensions between human-centric IAM and agent-native policy models.
