Hacker News: dend

New comment by dend in "Zero-Touch OAuth for MCP"

dend — Fri, 19 Jun 2026 15:04:48 +0000

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/

New comment by dend in "Zero-Touch OAuth for MCP"

dend — Fri, 19 Jun 2026 03:04:19 +0000

Was great collaborating with you and your team on this!

New comment by dend in "Zero-Touch OAuth for MCP"

dend — Fri, 19 Jun 2026 03:02:44 +0000

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.

New comment by dend in "Zero-Touch OAuth for MCP"

dend — Fri, 19 Jun 2026 01:59:48 +0000

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

New comment by dend in "Zero-Touch OAuth for MCP"

dend — Fri, 19 Jun 2026 01:59:22 +0000

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.

New comment by dend in "Zero-Touch OAuth for MCP"

dend — Fri, 19 Jun 2026 01:57:27 +0000

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.

New comment by dend in "Zero-Touch OAuth for MCP"

dend — Fri, 19 Jun 2026 01:56:13 +0000

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.

New comment by dend in "Zero-Touch OAuth for MCP"

dend — Fri, 19 Jun 2026 00:32:38 +0000

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

New comment by dend in "Zero-Touch OAuth for MCP"

dend — Fri, 19 Jun 2026 00:31:41 +0000

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!

New comment by dend in "Zero-Touch OAuth for MCP"

dend — Fri, 19 Jun 2026 00:30:15 +0000

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

New comment by dend in "Zero-Touch OAuth for MCP"

dend — Fri, 19 Jun 2026 00:06:43 +0000

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!

New comment by dend in "Zero-Touch OAuth for MCP"

dend — Fri, 19 Jun 2026 00:05:19 +0000

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.

New comment by dend in "Zero-Touch OAuth for MCP"

dend — Thu, 18 Jun 2026 23:56:42 +0000

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.

New comment by dend in "Apideck CLI – An AI-agent interface with much lower context consumption than MCP"

dend — Mon, 16 Mar 2026 18:34:56 +0000

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.

New comment by dend in "Apideck CLI – An AI-agent interface with much lower context consumption than MCP"

dend — Mon, 16 Mar 2026 16:23:30 +0000

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.