You might not need an MCP

MCP somehow escaped the typical tool extinction event. Now, when you need an agent to interact with a browser, a database, or an internal service, there’s an increasingly obvious answer: use MCP. It’s easy to see why. It’s a well-designed protocol that solves real problems. But the real question isn’t whether MCP is good; it’s whether it’s the right trade-off for what you’re trying to build. Right now, it’s often being adopted as a default rather than a deliberate decision.

The cost that rarely shows up in discussions is context. MCP servers are designed to be general-purpose, exposing a wide set of tools that become part of the model’s context whether they’re used or not. In practice, this can dramatically increase token usage, often consuming far more tokens than a focused, purpose-built integration. And that’s not a one-time cost. It’s a recurring tax on every run, every session, every workflow your agents execute.

There’s also the cost of complexity. Adopting MCP means inheriting abstractions, release cycles, and design decisions you don’t control. The moment your use case doesn’t fit perfectly, you’re no longer building your system. You’re adapting someone else’s.

To be clear, MCP solves a real and difficult problem extremely well: enabling external users to connect their own accounts to your agent without you handling credentials. If your product depends on users bringing their own integrations, like Gmail, GitHub, or Slack, MCP is often the right choice.

But many systems don’t have that requirement.

In many cases, you’re connecting agents to APIs you already own, using credentials you already manage, within infrastructure you already control. There’s no external consent flow, no user-managed connections, and no need for a generalized integration layer. Even for non-technical users, repetitive tasks and integrations can be packaged into simple, reusable skills that achieve the same outcome without introducing a full protocol layer.

In that context, the decision should change.

Instead of asking, “Should we use MCP?” ask, “What problem does MCP solve for us?”

If there isn’t a clear answer, then you’re likely paying for complexity you don’t need.

A simpler approach is often more effective: document your APIs clearly, provide a small set of focused scripts or examples, and let the agent generate the integration logic. Modern models are capable of writing and adapting code without requiring a full protocol layer.

Every abstraction introduces cost. MCP is no exception.

Use MCP when it solves a real problem in your system.

Avoid it when it doesn’t.