dend

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/

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.

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

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.

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

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!

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

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.

Core contributor behind this project. If folks have any feedback, we're all ears!

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.

Can only speak for the authorization spec, where I am actively participating - zero. The entire spec was written, reviewed, re-written, and edited by real people, with real security backgrounds, without leaning into LLM-based generation.

For local servers this doesn't matter as much. For remote servers - you won't really have any serious MCP servers without auth, and you want to have some level setting done between client and servers. OAuth 2.1 is a good middle ground.

That's also where, with the new spec, you don't actually need to implement anything from scratch. Server issues a 401 with WWW-Authenticate, pointing to metadata for authorization server locations. Client takes that and does discovery, followed by OAuth flow (clients can use many libraries for that). You don't need to implement your own OAuth server.

Just to add one piece of clarification - the comment around authorization is a bit out-of-date. We've worked closely with Anthropic and the broader security community to update that part of MCP and implement a proper separation between resource server (RS) and authorization server (AS) when it comes to roles. You can see this spec in draft[1] (it will be there until a new protocol version is ratified).

[1] https://modelcontextprotocol.io/specification/draft/basic/au...

Author of the article here (thank you mpweiher for the submission). Pi-Hole has been, hands-down, the best infrastructure investment in our household. At this point I have 2MM+ domains blocked and the performance has been great.

Great news - Aaron has been a core reviewer and contributor to the aforementioned RFC.

Can't take any credit - it's a massive effort across many folks much smarter than me.

Coordinator of the authorization RFC linked in this post[1].

The protocol is in very, very early stages and there are a lot of things that still need to be figured out. That being said, I can commend Anthropic on being very open to listening to the community and acting on the feedback. The authorization spec RFC, for example, is a coordinated effort between security experts at Microsoft (my employer), Arcade, Hellō, Auth0/Okta, Stytch, Descope, and quite a few others. The folks at Anthropic set the foundation and welcomed others to help build on it. It will mature and get better.

[1] https://github.com/modelcontextprotocol/modelcontextprotocol...

I am working on a reverse-engineered SDK for Stream Deck devices, called DeckSurf:

https://deck.surf

The SDK is open-source and on GitHub:

https://github.com/dend/decksurf-sdk

It's a hobby project, but one that I love working on because it unlocks some _really_ great hardware to be open to do anything I want it to be rather than be constrained by out-of-the-box client software that asks me to sign in with an account to get an extension installed.

I amended the description to better reflect the work. Thank you for the feedback, I appreciate the pointers to the IndieWeb and Maggie's sites.

Shockingly, they do! Quite a few folks that I've talked to recently expressed that they are subscribed to more than one email newsletter and read them fairly consistently.