When MCP earns its overhead, and when a direct API is better

One question settles most of these arguments: will more than one AI application need this capability?

UpdatedJuly 28, 2026

When MCP earns its overhead, and when a direct API is better

I’m Vamsi, a builder focused on production AI systems. I write Production AI Field Notes to break down the architecture behind reliable LLM apps, RAG, agents, multi-agent workflows, evaluation, observability, safety, and governance. My goal is simple: help builders move beyond impressive AI demos and design systems that can be tested, operated, trusted, and improved in the real world.

Comments

Join the discussion

No comments yet. Be the first to comment.

5 Days of MCP for Production AI

Part 5 of 5

What the Model Context Protocol actually standardises, and what it leaves to you. Hosts, clients and servers, the three primitives, transport as an ownership decision, and when a direct API is the better call.

Start from the beginning

What the MCP protocol actually standardises

It settles how capabilities are described and discovered. Every decision about whether to trust them is still yours.

More from this blog

Autonomy is a runtime decision, not a model decision

Agents get more capable by default. They only get bounded on purpose.

Jul 30, 20263 min read1

Autonomy is a runtime decision, not a model decision

A clean connector does not make a reliable agent

Connector correctness and agent behaviour are separate problems. Most teams only test the first one.

Jul 27, 20262 min read

A clean connector does not make a reliable agent

Tools, resources and prompts are not interchangeable

Choosing the wrong primitive hands the model authority a person was supposed to hold.

Jul 25, 20262 min read1

Tools, resources and prompts are not interchangeable

Where your MCP server runs is a production decision

Transport looks like a technical detail during the demo. It is really a choice about ownership, reachability and trust.

Jul 24, 20263 min read77

Where your MCP server runs is a production decision

The Production Layer

66 posts

The Production Layer is a practical publication for builders moving from AI demos to reliable production systems. Sixty posts in order, plus eight specialist tracks, covering the real engineering decisions behind LLM apps, RAG, agents, multi-agent workflows, evaluation, observability, safety and governance.

Teams tend to land in one of two ditches. Either MCP goes everywhere, including in front of an internal function the app already calls directly, or it goes nowhere and every AI feature reimplements the same integration with slightly different bugs.

Both come from skipping the question rather than answering it badly.

The question that settles it

Will more than one AI application need this capability?

If the answer is no, and it is honestly no rather than aspirationally no, a direct API call is better. You keep the call stack short, the failure modes obvious and the debugging local. Wrapping an internal function in a protocol layer to reach your own database is ceremony.

If the answer is yes, MCP starts paying for itself, because the things it standardises are exactly the things that get reinvented inconsistently: discovery, schemas, error shapes, session handling.

Situation	Reach for
One app, internal function, stable contract	Direct API call
One app, model needs to choose when to act	Function calling
Several AI clients, same capability	MCP server
Capability owned by a different team	MCP server
Third parties will connect to it	MCP server, with real versioning

Where the overhead is real

MCP costs you a process boundary, a schema contract and something new to operate. That last one is the part teams underestimate.

An MCP server other people depend on is a platform component. It needs release notes, because a schema change is a breaking change. It needs traces correlated with the calling agent, or debugging becomes archaeology across two systems. It needs tests that run when the underlying API changes, not when someone remembers.

If nobody is prepared to own those, the honest choice is a direct call today and an MCP server when a second consumer actually appears. Speculative platform work ages badly.

Where it clearly wins

Reusable, AI-facing capability surfaces that several clients need to discover at runtime. Anything crossing a team boundary, where a described contract beats a shared Slack thread. Anything you want a consistent audit trail for, regardless of which application triggered it.

That is a narrower set than the enthusiasm suggests, and a much better hit rate.

Choose the boundary on purpose. The cost of the wrong choice is not that it fails immediately, it is that it works just well enough that nobody revisits it.

Part 5 of 5 Days of MCP for Production AI.

Command Palette