Hacker News

I think that this extension points out other benefits to MCP over skills:

   * centralized control
   * ease of use for employees
   * auditing/compliance
   * deployment model

These options are simple, but not as easy as this extension makes rollout of a new MCP server to an employee.

I’m work on a platform for restaurant reviewing with your friends, and (after a few stumbles) MCP definitely seems the way to go. Normies will not hunt down their claude directory and paste a skill file. “Connections” is something they understand, and pasting the mcp or finding it in the marketplace is easier for them.

TBD if having agent access to places and reviews is helpful, hah!

Mcp allows a fantastic audit trail also. As well as allowing segregation of responsibilities - ie authenticating 6 linear accounts across 6 clients and then deciding which one to use with deterministic audited methods

> The real valuable capability MCP offers over skills/CLI is

The real lesson is that MCP vs skills is not a binary. They are simply different tools. Each may or may not be better given different requirements.

Which is better, a knife or a saw?

Aside from that, MCPs also allow connecting an external platform without a runtime environment. Every time this topic comes up, engineers act like Claude Code was the only application for AI agents, while there's tons of use cases in other verticals aside from coding. The harness is not running on a local machine, but rather an isolated and restricted container in some cloud deployment, where running arbitrary code would be a big nope. But you still want customers to be able to connect their existing tools to your agent.

MCP is the perfect answer for this - it gives an agent a connector with built-in authentication to all kinds of additional tooling. Skills just don't qualify here at all.

MCP tool search fixes the major issue imo, MCP clears skills/clis in every other way

I agree that having auth outside of context window is good.

But the real value of MCP is adding a semantic layer on top of APIs. Skills are client side and don’t know the server’s capabilities. MCP lets the server explain its API in natural language so clients who have no prior knowledge of the server, it’s API, or its domain can use it intelligently.

I used to think MCP was dumb. I’ve written to large MCP servers, one for CAD and one for music, and I am a complete convert.

I don't think you are missing anything obvious. Entra ID doesn't support DCR, and the state of the ecosystem here is suboptimal.

The typical way to do MCP OAuth is with traditional up-front registered clients. However, in practice a lot of MCP clients work with an assumption that DCR works, and as you point out don't offer an option to specify a client ID.

However, some clients do support that (ad: our tool Erato does[0]), and the typical solutions deployed in enterprises do, where MCP access is usually centralized via a web UI like ours. One alternative that also exists is are MCP gateways, which do pre-registred oauth between the gateway and service, and allow for DCR between the gateway and clients.

[0]: https://erato.chat/docs

I actually implemented this yesterday. The gist is this library runs the MCP server: https://csharp.sdk.modelcontextprotocol.io/concepts/identity...

Then I build an authbroker application using openid to handle client registration and build the jwt. End result is something that can determine tool availability and permission using an employees department, or other criteria.

So yeah the dynamic client registration is needed.

We had the same issue with the client_id and for security reason we weren't willing to enable DCR.

What we ended up doing, was the app proxying the OAuth flow, to inject a hardcoded client_id. So we lie to the MCP client telling it we support DCR while behind the hood we use a standalone client_id as usual for the MCP.

If you want to take example at it https://gist.github.com/erebe/a5de36d42214721b2466fb0e66f61c...

Yeah, I recently documented how to use pre-registered clients with FusionAuth[0] (my employer). DCR's newer, better sibling CIMD is on our radar and under active discussion[1], but not currently available.

An alternative to the proxy you suggest is to generate a new Entra client id (with PKCE enabled) for every MCP client in a developer portal or similar, then have the user configure their client with that client id. Here's the CLI command I found to do this[2], but I bet there's an API too. Here are config instructions for Claude Code[3] and ChatGPT[4].

Client pre-registration is acceptable, but not optimal, for developers, and is a first class citizen in the spec[5]. If your main audience is internal and you can expect them to follow configuration instructions to get access to the MCP server, this approach can work.

But it's definitely not acceptable for widespread, public integrations if your audience is not developers. That is where a lot of the power and opportunity for MCP lies.

0: https://fusionauth.io/docs/extend/examples/controlling-acces...

1: https://github.com/FusionAuth/fusionauth-issues/issues/3230

2: https://learn.microsoft.com/en-us/cli/azure/ad/app?view=azur...

3: https://code.claude.com/docs/en/mcp

4: https://developers.openai.com/api/docs/guides/developer-mode

5: https://modelcontextprotocol.io/specification/2025-11-25/bas...

Software and quality of life is worst because of these companies. So congrats to them indeed.

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.

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

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.

Great work, thank you for doing this. Just so I understand, this isn't yet available yet, right? Still in SEP stage?

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?

Was great collaborating with you and your team on this!

There's theoretically nothing really stopping this integration from working in the consumer space - you just need to establish a trust relationship (e.g., if I am logged in with GitHub, also log me in to Sentry automatically). There is more work ahead here, but as you said - the most obvious _current_ use-case is enterprises, where admins do not want individual employees clicking around picking random credentials they have.

Hey - one of the lead maintainers of the MCP project here. There are a lot of scenarios where this simply won't scale (both from a usability and security standpoint). Cookies were made for the browser. MCP servers and clients often operate in environments where that is not a guarantee.

You're just asking for your credentials to get stolen. Long lived creds are a huge liability.

Love more adoption of EMA and, of course, better infra for MCP developers. Thanks for such a quick turnaround on this feature work!

In regular OAuth, end users consent to share their data with applications individually. This makes sense for consumer usecases, where the end users own their data. But it doesn't make sense for many business usecases, where the business is the entity that should control data sharing and access, not the end user. As an employee at Acme, I shouldn't decide to link my Acme Google Drive data to Claude or ChatGPT, that should be the decision of my IT Department.

Enterprise-Managed OAuth, or Cross App Access (XAA), brings this IT-Admin centrally controlled sharing model into the OAuth framework so it works with the existing ecosystem.

There's also a great UX benefit from moving data sharing consent management from employees to IT Admins - it means that employees don't need to sit through a bunch of OAuth flows to link their accounts together. Their IT Admin has already set up all the sharing controls. Everything plugs in together and should Just Work from day one. Think joining a new company on the first day and your Slack is already linked to your Zoom, your Drive, your Calendar, etc...

Advantage is user has no control/is not needed to consent about what apps they're authorizing to share their information between each other, bacause the decision to delegate access is at the IdP policy level. User many never know which apps/services were authorized to share their information. Wait, is that an advantage? ;-)

Yeah, I read this and thought "makes total sense that Okta would be one of the prime movers behind this". The more I think about it, the more this is just like an app dashboard that an employee can use to access many different apps and that the enterprise can use to control and monitor access. So it makes total sense that they solved this (very real) problem.

I like one of the author's characterizations[0].

> Now employees no longer have to connect MCP servers manually and wait for a series of OAuth and login prompts. Once you log in to Claude from Okta, all the preconfigured MCP servers are already connected! It's not every day you get to improve both usability and security!

0: https://aaronparecki.com/2026/06/18/12/claude

The standard itself is not MCP-specific. As long as the client and the server adopt ID-JAG, they're golden.

RFC draft: https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a...

What's interesting about this standard is that it's not really MCP-specific. It can work just as nicely for any other workload - it just requires the authorization server/IdP to support it and the receiver to know how to handle the trust relationship.

We're always looking at making it a smoother experience - it's a top pain point for developers and IT admins alike. If you have feedback - feel free to send it my way!

FWIW, we never vibe-coded the spec to begin with, but yes - auth is a continuous learning process, and we're lucky to collaborate with some really talented folks both inside and outside the company (e.g., this launch we worked closely with Okta to see how we can best wire things up) to make this a smoother experience. Keep the feedback coming!

Why do people downvote this.. If your mediocre ai agent needs to use something that requires authentication you should be abstracting away the authentication, provide it a cli with cmds that have authentication baked in.

I thought we were all smarter than directly giving agents access to all of our long lived tokens

Why is it delusion? What are better ways to make LLM talk to other services?

MCP is just an API designed to be token frugal