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.

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

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.

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?

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

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.

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

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

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

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!

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

MCP is just an API designed to be token frugal