When MCP Is the Wrong Choice (And When It's the Right One)

MCP is not always the right answer. Sometimes a plain REST API is better.

This is a technical breakdown of when to use MCP, when to avoid it, and the architecture patterns that actually work in production — from someone who has shipped both.

What MCP Actually Is

The Model Context Protocol is a standardized way for AI models to interact with external tools and data sources. It defines a transport layer, a tool-definition schema, and a discovery mechanism. The value proposition: instead of building custom integrations for every model-tool combination, you build one MCP server and any MCP-compatible client can use it.

This is genuinely valuable — when the use case warrants it. The problem is that MCP has become a buzzword, and teams are adopting it for use cases where it adds complexity without value.

When MCP Is the Right Choice

1. You have multiple AI clients that need the same tools. If you're building one tool server for Claude, GPT, Gemini, and local models to all use, MCP's standardization pays off. Each client speaks MCP; you build once.

2. Your tools are stateful and long-running. MCP's transport layer handles streaming, cancellation, and progress reporting. If your tools run long jobs (builds, deployments, data processing), MCP's primitives are better than building your own.

3. You need dynamic tool discovery. MCP servers can advertise their capabilities at runtime. If your tool set changes dynamically (plugins, extensions, user-configured integrations), MCP's discovery mechanism is useful.

4. You're building a platform, not an application. If you're building infrastructure that other teams will build tools on top of, MCP provides a standard interface. This is the "platform play" — and it's the strongest case for MCP.

When MCP Is the Wrong Choice

1. You have one AI client and a fixed set of tools. If you're building an internal app that uses Claude (or GPT, or any single model) with a known set of tools, MCP adds a protocol layer with no benefit. A direct function-call integration is simpler, faster, and easier to debug.

2. Your tools are simple CRUD operations. MCP's value is in standardizing complex tool interactions. If your tools are "create user," "get user," "update user," "delete user" — a REST API is simpler, more standard, and better supported by existing infrastructure.

3. You're optimizing for latency. MCP adds a protocol layer. Every tool call goes through MCP's serialization, transport, and deserialization. For latency-sensitive use cases (real-time UIs, high-frequency calls), this overhead matters. A direct integration avoids it.

4. Your team doesn't have MCP expertise. MCP is new. The tooling is immature. Debugging is harder than debugging a REST API. If your team hasn't worked with MCP before and your timeline is tight, the learning curve will cost more than the standardization saves.

5. You're building a proof-of-concept. For a PoC, use whatever is fastest to build. That's almost never MCP. If the PoC proves valuable, you can refactor to MCP later — or not, if the direct integration works fine.

The Architecture That Actually Works

For production MCP deployments, here's what I've seen work:

1. MCP server as a thin wrapper, not a business-logic layer. The MCP server should handle protocol concerns (tool definitions, transport, discovery). Business logic lives in a shared library or service that both the MCP server and other interfaces (REST API, CLI, web UI) can call. This avoids coupling your business logic to MCP.

2. Explicit tool boundaries. Each MCP tool should do one thing. "Search documents" is a good tool. "Search documents, summarize results, and send an email" is three tools poorly disguised as one. Composability beats monolithic tools.

3. Structured error handling. MCP clients need to handle errors gracefully. Return structured errors with error codes, not just error strings. This lets clients implement sensible retry/fallback logic.

4. Observability from day one. Every tool call should be logged with: tool name, input (sanitized), output (sanitized), duration, error (if any). Without this, you're flying blind in production.

5. Versioning. MCP tools change. Version your tool definitions so clients can detect breaking changes. This is unglamorous infrastructure work that pays off the first time you need to change a tool signature.

The Honest Assessment

MCP is a good protocol for a specific class of problems. It's not a silver bullet. The teams I've seen succeed with MCP are the ones that adopted it for the right reasons (multi-client, stateful tools, platform play) — not the ones that adopted it because it was the new thing.

The teams I've seen struggle adopted it because they felt they should, then discovered they'd added a protocol layer to solve a problem they didn't have.

The question isn't "should we use MCP?" The question is: "what problem are we solving, and does MCP solve it better than the alternatives?" Sometimes the answer is yes. Often it's no. Knowing the difference is the actual engineering judgment.

---

For teams evaluating MCP adoption, I offer a technical audit that maps your use case against MCP's strengths and weaknesses — and tells you honestly whether to adopt it. No slideware.