When MCP Makes Sense (And When It Doesn't)

For the past year, the AI engineering community has had a default answer for integration: MCP. The Model Context Protocol shipped, every major model provider supported it, every infrastructure vendor announced support, and the framing took hold — “you must integrate using MCP, as it’s the USB-C of AI agents.”

Paul Iusztin, the founding AI engineer at a vertical AI startup and author of LLM Engineer’s Handbook (~20,000 copies sold), tried that path. His team built MCP servers for every integration their financial-advisor product needed. They used none of them. The article he wrote about it — “We Killed RAG, MCP, and Agentic Loops” — is now one of his most-discussed pieces. Not because MCP is bad, but because it’s been overprescribed.

The clearest line he gave during our recording: “If you have a hammer, you see nails everywhere.”

Where MCP works

Paul still uses MCP. But only in a specific pattern: as a plugin layer for dev tools he doesn’t control.

“If I use Claude Code and I just want to hook to my Gmail to do some basic stuff, like read my emails — I still think it’s amazing,” he says. The same goes for Cursor, Claude desktop, or any tool where the user controls the orchestration through a standardized integration layer. MCP shines when it sits between two systems that genuinely benefit from a swappable contract: a host application (the dev tool) and a service (Gmail, GitHub, a database).

The MCP-as-plugin pattern matches what the protocol was designed for. The host doesn’t know what services will plug in. The service doesn’t know what hosts will call it. The standard makes both sides interoperable without bilateral integration.

This is also where most engineers experience MCP — through Claude Code, through Cursor’s MCP support, through one-off integrations they install. It works. It feels magical. It generalizes.

Then engineers carry the pattern into their own products and reach for the same tool.

Where MCP breaks

The breakage happens when you’re building the application yourself — when you control the orchestration code, the agent logic, and every integration. In that situation, MCP stops being a swappable contract and starts being an extra layer of abstraction between you and the API you’re already going to call.

Paul’s team learned this the hard way. They wanted to integrate with email providers, document services, and calendar systems. Each provider offered an MCP server. The team thought: why write custom integration code when MCP exists?

“Our MCP server work was sitting on our server and it wasn’t hooked directly to the client. We connected on our server and ultimately we just ended up writing custom MCP servers for each of our clients,” he explains. “And we haven’t used any of them because they were too rigid or custom use case, they just did not have, weren’t updated enough, or they just did not add yet an MCP server.”

The translation: MCP forces you to either (a) accept whatever the third-party MCP server provides — which is often a least-common-denominator API — or (b) write your own MCP server that wraps the underlying API anyway, just so it speaks the protocol. Either way, you’ve added layers without adding value.

The deeper cost is dependency bloat. “If you start using MCP just with the idea that maybe I will use it, maybe I will not, you will just add this extra layer that adds useless complexity,” Paul says. “Especially in this world of AI, you want to keep it as dependency-free and simple as possible so that AI can actually write good code for you and not get lost in so many abstraction layers.”

The decision rule

The pattern Paul argues for is simpler than the framework debates suggest. Two questions:

Do you control the host (the orchestration code)? If yes, you don’t need MCP. Write tools directly. Wrap the API in a function. You have full control over the schema, the retries, the error handling, the rate limits.

Are you the host, integrating into someone else’s tool? If yes, MCP is the right protocol — that’s exactly what it was designed for. Ship an MCP server alongside your product so users of Claude Code, Cursor, or any other MCP-compatible tool can integrate without writing custom code.

In practice, this means most application developers should skip MCP for internal integrations and use it only for outbound surfaces — places where they want to be discoverable by tools they don’t control.

Why this matters for production AI agents

The deeper principle in Paul’s article isn’t about MCP specifically. It’s about the engineering instinct that drives over-architecting. “If one solution is hard, you shouldn’t put it everywhere,” he says. The hammer-nails problem.

Production AI agents fail at scale not because the model is wrong, but because the architecture has too many layers. Each abstraction adds a place for something to break. Each protocol adds a dependency. Each “best practice” adds work that may or may not pay off.

The teams shipping reliable AI agents are removing complexity, not adding it. MCP is a tool with a real job. That job is dev-tool integration, not internal application architecture. Match the tool to the job and the agent gets simpler. Force the tool everywhere and the agent gets brittle.

FAQ

When should I use MCP for my AI agent?

Use MCP when you’re shipping a server that should be callable from dev tools you don’t control — Claude Code, Cursor, Claude desktop, or any MCP-compatible host. MCP is right when the integration goes outbound. Skip MCP when you’re building an application where you control the orchestration code and can call APIs directly.

Why did Paul Iusztin’s team kill MCP in their product?

His team built custom MCP servers for each third-party integration (email, documents, calendar) needed by their financial-advisor product. None made it to production. Most third-party MCP servers were too rigid, out of date, or didn’t exist. Writing custom MCP wrappers added abstraction without value, so they replaced them with direct API calls.

Is MCP the same as a function-calling tool?

No. Function-calling tools are functions you define inside your application code, callable directly by the model. MCP is a protocol for exposing those tools across a network boundary, with a standardized schema. If you control both ends, function calls are simpler. MCP adds value when you don’t control one end — like exposing your service to Claude Code.

What’s wrong with using MCP everywhere?

Using MCP for every integration adds abstraction layers, dependency bloat, and indirection between your code and the underlying API. Each layer is a place for failure. AI coding tools also struggle with deeply abstracted code — keeping the stack flat helps both human readability and AI-assisted development. Overuse turns a useful protocol into a tax.

Should I write an MCP server for my SaaS product?

Probably yes — but only as an outbound surface. If your product would benefit from being callable inside Claude Code, Cursor, or other MCP-compatible dev tools, ship an MCP server. This makes you discoverable to the AI-tooling ecosystem. Use a thin wrapper over your existing API rather than rewriting your service around MCP.

How does MCP compare to direct API integration?

Direct API integration gives full control over schema, retries, rate limits, and error handling. MCP adds a standardized contract between hosts and servers — useful when either side is unknown or interchangeable. For internal applications where you control both sides, direct integration is simpler. MCP is right when interoperability with external tools is the actual requirement.

Why does MCP feel powerful in dev tools but weak in production apps?

In dev tools (Claude Code, Cursor), MCP solves the actual problem — connecting any service to any host through a standard contract. The user benefits from the swappability. In production apps where one team controls both the orchestrator and the integrations, swappability isn’t a value — it’s overhead. The protocol’s strength is contextual.

Is MCP dead?

No. MCP is a useful protocol for the right pattern: outbound surfaces that need to integrate with dev tools or any host the developer doesn’t control. The critique isn’t of MCP itself — it’s of MCP-by-default. Like RAG, MCP works when matched to the right use case and adds friction when used as a standard component without that match.