The best argument for MCP might be much smaller than the hype: keep authentication outside the model’s context window. That sounds almost disappointingly narrow, but I think Sean Lynch is mostly right.
If you strip away the grand claims about a universal tool layer, the concrete value is security and control. An agent should not be handed raw API keys, bearer tokens, or broad tenant access in its prompt or harness if there is any cleaner option. Microsoft’s own MCP guidance leans in this direction: Foundry supports project connections for key-based auth, Microsoft Entra identities, and OAuth identity passthrough, specifically so credentials are not hard-coded into the app and so access can be scoped per agent, per project, or per user.
That is the part I’d take seriously. The rest is still a bit messy.
Why is MCP as an auth boundary useful?
The practical win is not “agents can call tools.” We already had ways to do that with skills, plugins, CLI wrappers, and plain APIs. The useful change is that MCP gives you a cleaner boundary for brokering access.
In Microsoft Foundry, for example, MCP auth can be configured through a project connection, and require_approval defaults to always. That default matters. It means the platform assumes tool use is risky until you explicitly relax it. For teams building Microsoft Copilot and AI agents, that is a much healthier starting point than shoving secrets into orchestration code and hoping nobody logs them.
A small but important detail from Microsoft’s docs: with OAuth identity passthrough, consent is per user and per tool connection, and Foundry blocks Microsoft-scoped tokens from being passed to untrusted custom or third-party MCP endpoints. Good. An agent should not get a blank check to your tenant just because someone connected a shiny new server.
What’s the limitation?
MCP does not magically solve over-permissioning. It just gives you a better place to solve it.
If you attach a badly scoped service principal, a high-privilege managed identity, or a project connection with broad access, MCP can still become a very tidy delivery mechanism for bad security decisions. The protocol is not the guardrail; your identity model is.
That is why I’m more interested in custom, narrow MCP servers and explicit approval policies than in giant “connect everything” demos. In practice, the best MCP server is often a thin broker over a small, purpose-built action surface. Sean’s “maybe the idealized form of MCP is just an auth gateway” line lands because most enterprise estates do not need more agent autonomy. They need better containment.
What I’d take from this
My verdict is simple: this is the right mental model.
Treat MCP first as a security and authorization pattern, not as a grand unification story for AI tools. If it helps you move credentials out of prompts, apply per-user consent, use least privilege, and add approval where needed, it is useful. If it becomes another abstraction layer hiding broad permissions and fuzzy ownership, it is worse than a direct API.
For teams building agentic automation workflows, that distinction matters. The second-order effect is governance: once auth is centralized, you can audit it, rotate it, and reason about who approved what. That is far more valuable than yet another demo where a model clicks around five systems.
So yes, MCP is promising. But mostly because it can be boring.
