There are two debates happening right now:
CLI vs MCP - should agents call the existing CLIs or use an MCP server? And API vs MCP - does wrapping a REST API in an MCP server add value, or just complexity?
Both focus on how agents call tools. What both aren't asking is, who holds the credentials when they do.
Fifty agents, fifty sets of keys
When one developer runs one agent on one laptop, credentials are simple. You store them locally, maybe rotate them, and move on.
But that's not where we're heading. Dozens of agents per team, each needing access to Slack, GitHub, Jira, Office 365, that legacy CRM, multiple SaaS tools, and all your internal APIs.
Some of those have CLIs. Most don't - they're SaaS products with REST APIs. If you're lucky - who knows how many production systems still use a global, password-protected admin account.
So every agent needs a separate API key, OAuth token, or username/password pair. For each downstream system. On every machine. And if you've ever managed API keys for a team, you know where this goes. Keys in .env files, shared over Slack, committed to repos, never rotated.
Now hand that problem to fifty autonomous agents.
What happened to SSO?
Most organizations with any sense of security have established SSO, spent years consolidating identity. Every SaaS tool, every internal system, every third-party integration flows through one identity provider.
When someone leaves, you disable a single account. When compliance asks about access controls, there's one answer - and you know exactly where to find it.
And now, agents are about to blow a wide open hole into everything you've built. Whether your agent calls a CLI, hits a REST API, or talks to an MCP server, it needs credentials. And if those credentials live on the agent's machine, they live outside your identity boundary.
Imagine a contractor wrapping up on Friday. You disable their SSO account, but their laptop still has three agents with API keys for your CRM, your internal docs, and your deployment pipeline. Those keys don't expire with the SSO account. Those agents can continue calling your APIs long after the contractor has moved on.
Remote MCP servers are identity boundaries
This is where remote MCP servers earn their place in both debates.
The CLI vs MCP crowd argues about token efficiency. The API vs MCP crowd argues about unnecessary abstraction. Neither side is talking about the nightmare of decentralized credential management.
Charles Chen makes this point well in MCP is Dead; Long Live MCP!. Most of the debate ignores the difference between MCP over stdio (local, and yeah, mostly pointless compared to raw curl or a CLI) and MCP over streamable HTTP (remote, centralized). Once MCP runs as a centralized server, users authenticate via OAuth and never touch the downstream keys.
As he puts it: "An engineer leaves your team? Revoke their OAuth token and access to the MCP server; they never had access to other keys and secrets to start with."
Now take that one step further. In most organizations, that OAuth isn't standalone - it flows through SSO. The MCP server becomes an identity boundary. Your users never store any API keys, custom tokens, or service accounts. One auth mechanism instead of one per machine per agent per API.
Disable the SSO account, and every agent loses access. To everything.
But we already learned this, right? Every microservice managing its own database credentials was a nightmare until we centralized secrets management. Agent credentials are the same problem, just one layer up.
Top comments (0)