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.
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.
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.
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.
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!
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!
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.
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.
More of the latter than the former. The protocol itself is constrained to a set of well-defined primitives, but clients can do a bunch of pre-processing before invoking any of them.
One of the MCP Core Maintainers here, so take this with a boulder of salt if you're skeptical of my biases.
The debate around "MCP vs. CLI" is somewhat pointless to me personally. Use whatever gets the job done. MCP is much more than just tool calling - it also happens to provide a set of consistent rails for an agent to follow. Besides, we as developers often forget that the things we build are also consumed by non-technical folks - I have no desire to teach my parents to install random CLIs to get things done instead of plugging a URI to a hosted MCP server with a well-defined impact radius. The entire security posture of "Install this CLI with access to everything on your box" terrifies me.
The context window argument is also an agent harness challenge more than anything else - modern MCP clients do smart tool search that obviates the entire "I am sending the full list of tools back and forth" mode of operation. At this point it's just a trope that is repeated from blog post to blog post. This blog post too alludes to this and talks about the need for infrastructure to make it work, but it just isn't the case. It's a pattern that's being adopted broadly as we speak.
One of the MCP Core Maintainers here. I want to emphasize that "If you see something, say something" very much works with the MCP community - we've recently standardized on the Spec Enhancement Proposal (SEP) process, and are also actively (and regularly) reviewing the community proposals with other Core Maintainers and Maintainers. If there is a gap - open an issue or join the MCP Contributor Discord server (open for aspiring and established contributors, by the way), where a lot of contributors hang out and discuss on-deck items.
The analogy that was used a lot is that it's essentially USB-C for your data being connected to LLMs. You don't need to fight 4,532,529 standards - there is one (yes, I am familiar with the XKCD comic). As long as your client is MCP-compatible, it can work with _any_ MCP server.
I am just glad that we now have a simple path to authorized MCP servers. Massive shout-out to the MCP community and folks at Anthropic for corralling all the changes here.
But where would you get bearer tokens? How would you manage consent and scopes? What about revocation? OAuth is essentially the "engine" that gives you the bearer tokens you need for authorization.
I wrote about it: https://den.dev/blog/mcp-confused-deputy-api-management/