You’ve probably spent the last few months feeling the pressure. Everyone is talking about the Model Context Protocol (MCP) like it’s the universal standard for AI agents. You’re terrified of being left behind, so you’re ready to rewrite your entire backend to support it. But before you drink the Kool-Aid, let’s look at what’s actually happening in the production trenches.
Standardization isn’t a feature; it’s a tax you pay for not knowing what you’re doing.
A recent Hacker News thread asked the question we all actually care about: Who is using MCP in production? The answers are a sobering splash of cold water. Yes, teams are using it. One developer built a bug-reporting tool that searches for duplicates and writes tickets. Another built a voice-based learning assistant. But when you dig into the comments, the hype collapses into reality. As one engineer bluntly put it: “I find clis or calling apis directly to be waaay cheaper and faster.”
Here’s the twist you didn’t see coming. MCP’s biggest risk isn’t losing to a better protocol. It’s that agent-native CLIs and APIs will simply absorb its use cases. MCP is solving an agent UX and discovery problem, not a fundamental capability gap. It’s a transitional abstraction—a band-aid for agents that aren’t quite smart enough to navigate raw tools yet.
The more you optimize for the agent’s convenience, the more you punish your own latency and bottom line.
The tension is real. The more standardized the interface, the more abstraction overhead you introduce. The more direct the integration, the less agent-friendly it becomes. Teams using MCP in production are highly selective. They aren’t deploying it everywhere. They use it when they absolutely need a standardized way for agents to discover remote resources. For everything else? They just let the agent use the CLI. One dev even admitted they only keep a Jira MCP server around because they set it up a while ago and haven’t bothered to rip it out.
If you’re evaluating whether to build on MCP, take a breath. Production usage is real, but it is selective. Weigh the standardization value against the added complexity. Don’t assume the hype means you must adopt it everywhere. Sometimes, the cheapest, fastest, and simplest tool is just the one you already have.
Don’t build a bridge when the river is already dry.
FAQ
Q: If MCP standardizes agent interactions, why not use it everywhere?
A: Because standardization is a tax. For internal tools, a direct CLI or API call is often cheaper, faster, and introduces less latency. MCP shines for discovery, not basic execution.
Q: So, when *should* I actually use MCP?
A: Use it when you need third-party agents to dynamically discover and interact with your resources without custom integrations. If it's just your own internal agents talking to your own tools, stick to direct APIs.
Q: Is MCP just a band-aid for bad agents?
A: Mostly, yes. As agents get better at navigating raw CLIs and APIs autonomously, the need for a standardized abstraction layer disappears. MCP is a transitional abstraction.