Hey folks - I am one of the folks at Anthropic that helped deliver this in partnership with Okta and a handful of MCP partners. We're very excited about this taking shape in Claude (in addition to the MCP spec, of course, where EMA is now a stable extension) and are looking to expand adoption to other identity providers and clients as well.
If you have any feedback, feel free to drop it in here! Always happy to hear about folks' experience and how we can make it better.
Long time no see! It's been a while since I've looked at MCP, but I think this does a really good job at making MCP more secure for organizations and addressing some of the weaknesses of dynamic client registration. Now that clients and approved redirect URIs can be setup directly by the IdP and organization, a lot of the attacks that were possible with DCR (confused deputy, phishing attacks, etc.) can be mitigated more broadly. It also makes it so servers don't have to implement as much authorization logic as they did before if the IdP or organization didn't support DCR, which is a pretty big advantage (especially if they combine MCP auth with existing API auth).
One major downside is consumer usage seems to still need DCR with this. I think this could potentially be addressed by existing consumer OAuth providers (Sign in with GitHub, GitLab, Google, etc.) adding support for registering static MCP clients/servers, clients shipping their static client IDs inside them, clients allowing users to sign in with GitHub/GitLab/whatever IdP, and letting the user self-manage connections on the IdP's site.
Overall, XAA/EMA seems vastly superior to DCR from a security perspective (and also usability too, since users don't have to configure as much!). The concerns I have are also much easier to address and have way less security impact than with DCR, since attackers don't get to register their own clients anymore and there are less pitfalls for MCP server developers.
This is great for normal "apps". We have a really deep need for a lower touch way for our users to interact with us agentically without setting up MCP. It'd be really great to have some sort of temporary session or out-of-band token storage available.
Here's our use case: During the sales cycle, the buyer and seller need to exchange a bunch of information then analyze it (which is increasingly agentic). The problem with MCP is the initial setup friction is far greater than users login in themselves and grabbing the information they need. MCPs are great for regular, frequent interactions - but create a lot of problems for these quick one-off sessions.
We'd really love a way to do something like this:
* In Claude: "Grab documents from X, Y, Z"
* Claude hits that website, it returns (1) basic usage information (2) a login link that the user can open in their browser
* User auths in their browser (annoying, but mindless)
* That callback returns a unique, short-lived, one-time token that gets exchanged on all future requests to the site.
Now, we can quickly auth users AND maintain a session state as they do things.
> The problem with MCP is the initial setup friction is far greater than users login in themselves and grabbing the information they need.
Can you tell me more about this? With just-in-time client registration (DCR or CIMD) it seems like the MCP registration would be pretty simple.
Is it the configuration of the MCP client to know about the MCP server that is the issue?
Does the website need to be able to advertise "here's the corresponding MCP server" so that the "claude hits website" step becomes "claude hits website, discovers MCP server"?
Yes, it’s the friction of setting up the MCP server in the first place. Especially, in environments where that is not straightforward or easy to do. When our users are looking for information, they don’t want to figure out how to setup the MCP.
I don’t think this is about advertising an MCP at all. All of this can be accomplished with plain old HTTP requests. I want to be able to tell users “tell your LLM do go to https://example.com/only-bots”.
There’s absolutely no need for an MCP, because the website will tell the LLM everything it needs to know, including other actions and endpoints available.
Have you seen WebMCP[0]? Had a customer ask about this recently.
It seems like it might be something of what you are looking for, since it leverages HTML to tell agents about website functionality.
One issue I see with WebMCP is that agents basically free-ride on user identity and authentication, which is problematic in some scenarios.
0: https://developer.chrome.com/docs/ai/webmcp
Fantastic news. Is there any communication between you folks and the Microsoft Entra (Azure AD) team? Would love to know if we can expect this soon or if will take a while.
We are in touch with the Microsoft Entra ID folks to see how we can better integrate EMA in their stack!
While you're at it, bug them a bit to finally add support for MCP servers in Copilot. I'm on an Odyssey to find a way for our customers to use our MCP within their Copilot environment…
Fantastic, appreciated.
Hiya, congrats on shipping!
Seems like the main use case is employees of companies. Is there an analogous use case/value for non-centralized users like customers or freemium users?
I'm struggling to think of one, but wonder what I'm missing.
Edit: I see you addressed this here: https://news.ycombinator.com/item?id=48594381
Great work, thank you for doing this. Just so I understand, this isn't yet available yet, right? Still in SEP stage?
It is available! The feature is available in Claude, with Okta being the first IdP to support it (hopefully more coming soon) and with a bunch of MCP partners launching with us today.
The underlying extension has been in the MCP protocol for some time and is now officially stable.
Anthropic is the only one with human readable tool names from the JUNE 2025 spec! So you guys are doing a great job and this is another example.
I'm just curious internally how you are seeing MCP adoption? It seems more and more connectors are created but are you seeing real adoption from users?
You don't actually need to ask me for that - a lot of the data is very public, and we've been on a roll announcing MCP partnerships, and developer adoption keeps going up. There is always room to make the protocol better, but it certainly has a healthy foundation.