Posted by niyikiza 20 hours ago
The real valuable capability MCP offers over skills/CLI is isolating the auth flow outside of the agent’s context window, and potentially out of the harness completely. This is valuable from a security perspective obviously. It’s also just a much easier user experience for normies and large businesses adopting AI tools. I hear all the context bloat and tool call redundancy complaints. But this structure for handling auth has real value.
Maybe the idealized form of MCP is just an auth gateway for the API and nothing else. That’d still be a win.
* 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.
https://modelcontextprotocol.io/community/working-groups/ski...
By tools, do you mean skills? Or do I misunderstand you?
Thanks for sharing your solution. I clicked around and the information on your site is sparse. The postgresql page[0] doesn't really illustrate how your system works; just says that it does.
Regardless, there's a big difference between a proprietary way to inject skills and MCP, a standardized way to control access and deploy AI compatible logic.
Your argument is fair but yea, we are seeing adoption because tools often map to users mental model of how they want to use the agent.
But let me know when you launch. My email is in my profile.
TBD if having agent access to places and reviews is helpful, hah!
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?
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.
But progressive disclosure is just a method that you can apply to lots of things to reduce context bloat. Any time you provide some kind of limited index or search to an AI and then let it expand that based on the circumstances of the request, it's progressive disclosure.
And one of the things you can apply it to is MCPs.
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 can use the `WWW-Authenticate` header to indicate a resource metadata URL for the client.
- I can use this to indicate an authorization server (Microsoft Entra) and a scope (for the app registration that handle which app roles each user is given to differentiate different capabilities for different users).
- I can NOT indicate a client_id, because that's just something that each client (agent) makes up on its own?
- To initiate a login on the .../authorize URL in Microsoft Entra, you need to pass a known client_id that matches an app registration in Microsoft Entra. Whatever the client makes up will surely not match anything in Microsoft Entra.
- I COULD in theory support dynamic client registration, but of course Microsoft Entra doesn't.
Is it even possible to make this work out of the box? The only way forward I can see is implementing my own dynamic client registration shim in front of Microsoft Entra that just returns the same static client_id to everyone, which matches an actual client_id in Microsoft Entra.
But surely this protocol actually works today for real Enterprises without workarounds? It feels like I must be missing something obvious.
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.
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.
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...
I wrote about it: https://den.dev/blog/mcp-confused-deputy-api-management/
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...
For the MCP nay-sayers - don't worry there's something here for you too :)
This is powered by a new token format called an ID-JAG - https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a... - and isn't MCP specific at all. ID-JAGs can be used for safe and secure data sharing anywhere where data is shared between applications that use the same SSO provider.
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.
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.
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.
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"?
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.
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.
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
The underlying extension has been in the MCP protocol for some time and is now officially stable.
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?
What folks dont realize is it is the "P" in MCP that throws people off. When you build a traditional app you have to build forms, ui, req/response handling, bidirectional channels, long running tasks, auth and so on.
With mcp 80% of this common layer is taken care for you. So mcp is really an "app framework" than a protocol (well there is that too).
Unified auth is a huuuge boost. Can't wait to see more cool things!
On a personal level, what I felt bit uncomfortable with is this idea of access being delegated on my behalf by IDP to client without making me aware about it. May be I am too used to the concept of user presence in the flows that happens on browser. This it evolving more towards centralizing the access for the machines.
Given in the enterprise environment the identity really belongs to the company instead of individual, its probably acceptable.
How its gets incorporated in customer identity is altogether a different challenge. Its probably not possible to have this kind of trust between IDP, client and the resource authorization server.
Reasons why this is a bad idea for consumer identity -
1. In Enterprise, the IDP is the single owner for the identity, so it essentially can do represent the user uniquely and sort of pretty much do anything it wishes for (includes deleting the identity)
2. In enterprise the IDP is the single authentication factor used by the downstream resource server (application), in other words the application just trusts the assertion
3. For consumer identity, the resource server owns the identity/user explicitly. Github may be one of the authentication factors that the user can use, but it may not be the only one.
4. For consumer identity, Github cannot delete the user account in downstream application.
Regardless, this protocol is going to create friction in adoption of new AI agents and MCP servers, to sell to enterprise they have to implement this and integrate with existing IDP's and resource servers. Using any new MCP server would require full evaluation lifecycle from security perspective. Its a good thing but its going to hurt the new players pretty bad in terms of adoption and discovery.
I hacked the spec to pass through a cookie via the oauth handshake to do this without needing an oauth server.
Its really dumb they don't want to allow this.
If no cookie, open webpage.
If cookie set, close and persist.
I literally wrote an 80 page mini book on MCP yet it frustrates me to no end.
I've been considering a similar approach for the web. Essentially, do a short-lived, one-time use token exchange for every single call back and forth.
* LLM: "I'd like to interact with your site"
* Site: "Great, here's first token. I will exchange it for a new one on the next call. Do not share with with another site. You can authenticate in your browser with this link: [example.com]"
* Then you can go back and forth.
It'd be rather annoying to auth in the browser every time, but it would enable a low-touch flow.
Long term, it'd be ideal to have some sort of out-of-band credential store/tool available, but this would start proving the concept out. Don't use it for highly sensitive stuff, but it would enable a lot of agentic flows that are currently blocked by high-lift MCP setup.
Many times what the server returns is dictated by what kind of client software a user is using. Cookies are obviously used by browser based clients, with full browser capabilities. MCP doesn't have those capabilities. How will the server know what to return?
I have separated handling for token based calls vs cookie based in my non-mcp projects.. because it suffers from the same issue.
Most of the endpoints, assuming the client talks to server using api's, work fine with cookies, some, do not.
We launched support today for C1 to act as an EMA identity provider (we mint the short-lived scoped tokens), so I'm excited to hook this up for Linear and some of the other MCPs we use, and get out of the business of constant OAuth flows. Claude has been doing this magically for some of their built-in connectors (at least Slack I think) and the experience is pretty great.
Disclosure: VPE at C1. We wrote up how we’re approaching it here if anyone’s in the weeds on this: https://www.c1.ai/docs/product/admin/enterprise-managed-auth...
> look inside
> there's a touch