"You'll end up with something like MCP once you introduce enterprise users" - yeah. The token efficiency debate is a single-developer optimization. The moment you introduce teams or compliance requirements, the question shifts to who manages the credentials.
With CLI, it's your machine, your keys. With direct API calls, keys live wherever the agent runs. Both work until a contractor leaves and their laptop still has active keys for your repos, your internal docs, and your CRM.
Remote MCP over streamable HTTP gives you a centralized auth layer. One SSO integration, one revocation point, one audit trail.
While the spec includes OAuth 2.1 now, that's only half the story. The real question is where the credentials live.
When your agent calls a CLI or curls an API, it uses credentials stored on the developer's machine.
For one person that's fine. But for 50 agents across a department, each needing keys for Slack, Jira, GitHub, your CRM, and a dozen internal APIs? You've recreated the pre-SSO world, except access is autonomous and at machine speed.
Remote MCP servers (streamable HTTP, not stdio) change that. The agent authenticates via OAuth/SSO, the server holds the downstream keys, and the user never sees them. Disable the SSO account and every agent loses access.
This is the same pattern as centralizing database credentials instead of baking them into every microservice config, just on a different layer.
The auth story is heavily overlooked by most folks that are solo-vibing and then think that advice, the tools, and the practices that work for 1 works for a team or org.
With CLI, it's your machine, your keys. With direct API calls, keys live wherever the agent runs. Both work until a contractor leaves and their laptop still has active keys for your repos, your internal docs, and your CRM.
Remote MCP over streamable HTTP gives you a centralized auth layer. One SSO integration, one revocation point, one audit trail.
I wrote about this angle here: https://dev.to/dennistraub/missing-from-the-mcp-debate-who-h...
reply