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

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.

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.

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

> 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?

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

There’s even a skills over MCP WG; and I typically deliver skills via tools in my MCPs intentionally. I find Claude and codex recall of skills via MCP tools to actually be higher than skills themselves, which I feel have an (unmeasured) less than 30% recall rate. I have to typically force skills to be loaded explicitly through / or $ depending on the flavor and skill graphs are very unreliable.

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.

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...

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!

For organizations it's definitely an advandtage, as it also allows for preventing data flowing to personal accounts. Right now, any employee could knowingly or unknowingly exfiltrate data, by just connecting to e.g. the personal instead of the organization's JIRA account, and there is essentially no standard way to guard against that as an organization.

That's also blind spot in normal OAuth and I was surprised to find that this was never addressed in all the years that non-MCP OAuth found adoption.

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

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...

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.

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!

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.

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.

This is bonkers.

Sure, if I’m a business, I will make a business decision to share, or not share, some resource with ChatGPT. But, if I do decide to share something with ChatGPT, I absolutely do NOT want it shared with every single ChatGPT thread, more or less how I don’t want it shared with every single tab an employee has open in a browser.

For your employee account yes its an advantage, and thats the target. Your personal account will still require consents.

Frugal is definitely not a word i would use in the same sentence as mcp

Depending on the setup, you just have to be really careful to avoid confused deputy scenarios.

I wrote about it: https://den.dev/blog/mcp-confused-deputy-api-management/

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.

Same!

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.

Agree.

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.

I've been working on an MCP for creating semi-deterministic flows in Claude code (essentially skills, but broken down into pieces). In order to track execution and state, I have the LLM pass the MCP a unique "execution id" with every call. This lets me programmatically step it through skills and know exactly where execution progress is.

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.

At the end of the day its wiring the flows to serve a purpose and can be wired in multiple ways. Some combination of client, IDP and resource server can come together to form a band and may provide this for consumer identity.

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.

We are in touch with the Microsoft Entra ID folks to see how we can better integrate EMA in their stack!

Isn't that what's solved by this method? Your SSO provider (e.g. Okta) is now what gates each employee's resource access for different MCP resources.

It's as frugal as your harness makes it. It's just a bunch of tools and a description of how to use them. Most mature harnesses do some kind of tool search and/or progressive disclosure. Many harnesses have some smarts to page out overwhelming results to a file so a model can grep/jq them easily. Some harnesses expose tool schema to models so their results can be directly transformed or even chained in [code mode](https://blog.cloudflare.com/code-mode/).

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…

As someone who has been creating agentic workarounds at my large employer and in a lot of conversations with security as a result, this does not seem to be a huge advantage from the company side. They are very much invested in users being aware of what they permit. The company does want the final say either with shutting down a compromised user or blocking one service from agents and allowing the other, but they 100% do still want employees to be actively engaged and applying their own consent.

Removing that from the employee also removes the employee from responsibility for any breach of information IMO, and companies definitely don't want that lol. What they do want is users to stop complaining about the annoying reauth every 8-12 hours for a dozen services which this does.

The kinds of wishlists I hear are more about users managing fine-grain service permissions for various agentic roles and managing which agents have access to which role, which leans the other direction. They want to allow users are to treat agents like cloud services and have a greater responsibility for applying least privilege, justify leak risks, etc. The onus to protect this data will always be an employee responsibility in the end.

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

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

It seems the state of the art for deploying skills is "copy this file and put it in this place" or "check out this repo and add a symlink" or "run this slash command to install the skill". (I'm not aware of any solution that pushes skills out.)

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

> the usual “MCP is dead, Skills forever” debate

Is that really a thing? Everything on the other side of the MCP boundary (at least how I'm using it) is deterministic and about 100x faster (not to mention safer) than inference.

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

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!

I don't think so.

The article is all about reducing friction. Suppose I start a conversation and enter some highly third-party-prompt-injectable request, perhaps "Fork github.com/some_third_party/coolproject and submit a PR to do such-and-such." That repo injects a prompt that attempts to do a tool call to steal all my money. If I indeed have a bank MCP configured, I absolutely want to be prompted!

Now I realize it's silly for the prompt to look like "Would you like to grant [OpenAI/Anthropic/whatever] access to such-and-such account with such-and-such OAuth resources?", but having some kind of explicit opt-in, per conversation, to MCP access seems really quite important. But the article all about reducing friction and avoiding prompts.

So maybe LLM providers will do a good job, but I'm not holding my breath.

I am with you on the challenges with fine grain authorization needs, to me that part is real hard. In a theoretical world the IDP would know all the roles and permissions available for the different authorization servers (downstream services). However centralizing something like this would require some adoption of how permissions are managed by different resource servers, that is a different battle.

What this gives your employer is the allow list of AI agents that you can use (the ones that can use your employer's IDP to access downstream MCP servers) and filters out all the MCP servers that do not implement this protocol. Essentially the threshold to use any AI agent or any MCP server would be a lot higher.

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

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

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.

Fantastic, appreciated.

The key here is the separation of target segment for this. Enterprise identities (you being an employee) are the target for this not the consumer identity (personal account). When you are an employee then the sensitivity and security of your account can be managed by your employer.

Other way to look it is that as an employee you will not be able to connect to any MCP server anymore unless its configured in your IDP.

Just to be clear, enforcing proper access control and data seperation is the job of a client (/harness), not the job of an LLM Provider (though of course the most popular clients are the first party clients for the LLM providers).

Ensuring that an LLM doesn't have free reign over calling any MCP tool at any point in time is one of the main jobs of a client (apart from the general data persistence, etc.), and one that's very dependent on the setup (e.g. many MCP servers expose public data where tool calling is mostly not that sensitive) and the acceptable risk profile.

This MCP extension also doesn't significantly change anything about tool calling control from the perspective of the client. MCP servers were previously also authenticated once per user, and not once per conversation or once per tool call.

<< The article is all about reducing friction.

I read the initial paragraph from the page and I had similar reaction with an additional touch of:

'There is a purpose for that friction.'

Claude CLI has plugins and plugin marketplaces that solve the problem you're describing.

There's a new standard in progress for skills over MCP

https://modelcontextprotocol.io/community/working-groups/ski...

Isn’t tool drift/version also a benefit? Especially in scenarios where the use must be standardized and up to date?

Yes, people conflated progressive disclosure as a method with skills as a particular implementation because skills became the first widely adopted use of progressive disclosure.

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.

There's some active discussions on task level authz and multi-hop delegation in the OAuth WG right now. WorkOS wrote a good overview of the open drafts [1]. (Disclosure: one of them is mine.) [1] https://workos.com/blog/oauth-multi-hop-delegation-ai-agents

All the points that you are mentioning, you can technically do with tools too. We do that at adaptive [1]. We are building privileges access stuff for agents, and it works. The usecases you are mentioning can be done with tools via our platform.

[1] https://adaptive.live

Skills can be about as deterministic. Consider GitHub MCP vs skill for GH CLI.

It might use the view_pr tool, or `gh pr view`, but in the end it's still performing a deterministic action.

The benefit might be that the GH skill can contain more domain specific information about GitHub, and you only pay the context cost when the skill is read.

Personally I generally avoid MCP and have skills for CLIs -- if one doesn't exist, then I author one. For example I have a CLI for Grafana, Discord, Sentry, etc.

https://github.com/shepherdjerred/monorepo/tree/main/package...

"Normies" pasting in MCP sounds like a nightmare from a security perspective.

> 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"?

I skimmed that. It seems to me:

(a) A major problem where one agent can give dangerous instructions to another.

(b) A desire for an “agent” to cleanly delegate permissions to another “agent”. I am extremely unclear as to what an “agent” is in this context. Is one’s OpenAI or Anthropic account an “agent”? How is (b) related to (a)?

(c) An observation that existing OAuth + JWT can’t really do (b) and that a new spec could allow delegation.

ISTM:

- (a)’s root cause is a complete lack of control on the portions of a repository that are interpreted by various tools in a trusted/privileged manner.

- (b) could be addressed by a capability or proxy system.

- Most services that offer OAuth or other types of API keys have absurdly coarse-grained permissions. GitHub’s OAuth cannot obviously even restrict to a particular organization, let alone a repository, and good luck blocking commits to .github. Cloudflare can’t restrict DNS operations to a particular host. A shocking number of major services have no concept of non-human accounts. The list goes on. Delegation is of dubious value in this setting.

- Why would one ever want to give a bearer token to an “agent”?

- Wouldn’t a proxy serve this purpose more flexibly and more universally?

I agree with the coarse permissions point, and I wouldn't bank on those services adding finer-grained scopes.

The idea in my draft is to do the attenuation and verification before the call reaches the service, enforced at the boundary, like the proxy setup you're describing. And the token wouldn't be a bearer token per se; there's proof of possession, and the constraints narrow at each hop and travel with the token, so the boundary can verify the chain itself rather than rely on a central authority. The design is inspired by macaroons and other capability-based access control work.

Full draft's here if you want to pick it apart: https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenu...

Yes, definitely the official directory for apps/connectors where possible, which security and vetting is a priority. It's similar in some ways to how it was/is with mobile where you have the official store vs directly running an apk.

Claude Code uses gh cli just fine without any skills.

> you can technically do with tools too

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.

0: https://adaptive.live/integrations/postgresql

> It might use the view_pr tool, or `gh pr view`, but in the end it's still performing a deterministic action.

No its providing a deterministic output. The action it takes is still not determistic, right, since it can be either of the two options.

I don't see the benefit or even the point of "more domain specific knowledge" in a skill especially for the example you shared.

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.

If "fine" is what you need, then ok. It can stumble its way to everything eventually.

With a proper skill it can one-shot even complex commands that require poking to gh api because the basic command set doesn't work. Or it knows how to track a running CI workflow efficiently without having to try three different methods.

Source: I daily drive Claude + gh cli.

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

Apologies about the sparse information. We’re preparing for a launch. Thought this would be a great place to make the comment. It is indeed a combination of tools and skills.

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.

No worries, always appreciate the discussion. Good luck on the launch!

You sound like someone who is technically well-versed with the landscape. would love to get some feedback from you.

Haha, so much to learn so I wouldn't say I'm well-versed.

But let me know when you launch. My email is in my profile.