MCP is the future in enterprise and teams.
It's as you said: people misunderstand MCP and what it delivers.
If you only use it as an API? Useless. If you use it on a small solo project? Useless.
But if you want to share skills across a fleet of repos? Deliver standard prompts to baseline developer output and productivity? Without having to sync them? And have it updated live? MCP prompts.
If you want to share canonical docs like standard guidance on security and performance? Always up to date and available in every project from the start? No need to sync and update? MCP resources.
If you want standard telemetry and observability of usage? MCP because now you can emit and capture OTEL from the server side.
If you want to wire execution into sandboxed environments? MCP.
MCP makes sense for org-level agent engineering but doesn't make sense for the solo vibe coder working on an isolated codebase locally with no need to sandbox execution.
People are using MCP for the wrong use cases and then declaring them excess when the real use case is standardizing remote delivery and of skills and resources. Tool execution is secondary.
So just to clarify, in your case you're running a centralized MCP server for the whole org, right?
Otherwise I don't understand how MCP vs CLI solves anything.
Correct.
Centralized MCP server over HTTP that enables standardized doc lookup across the org, standardized skills (as MCP prompt), MCP resources (these are virtual indexes of the docs that is similar to how Vercel formatted their `AGENTS.md`), and a small set of tools.
We emit OTEL from the server and build dashboards to see how the agents and devs are using context and tools and which documents are "high signal" meaning they get hit frequently so we know that tuning these docs will yield more consistent output.
OAuth lets us see the users because every call has identity attached.
Sandboxing and auth is a problem solved at the agent ("harness") level. You don't need to reinvent OpenAPI badly.