When You Do Not Need MCP: The Real Cost of Each Server

A minimal MCP server in TypeScript fits in about forty lines. What does not fit in forty lines is its operating cost: one more process to start, an initialization handshake, a lifecycle to watch and, above all, a tool catalogue that the model reads in full at the start of every conversation. Ten tools with generous descriptions eat a couple of thousand context tokens before the user has typed a single word.

On 10 September HackerNoon published a practical guide on when you do not need MCP, written from the point of view of someone who has been building integrations for months. The thesis runs against the enthusiasm of the past year: the Model Context Protocol solves a distribution and discovery problem, not a capability problem. If you do not have that problem, you are paying the bill without getting the goods.

What MCP actually solves

MCP standardises how a client you do not control, whether that is Claude Desktop, Claude Code or a third party IDE, discovers tools, reads their schemas and calls them. The word that matters is discovers. The client knew nothing about your API, it starts the server, asks for the tool list, receives names, descriptions and JSON Schema, and can use them without anyone recompiling or redeploying.

That contract is worth money when there is a real boundary between whoever writes the tool and whoever consumes it. If your agent and your functions live in the same repository, ship together and are only called by your own backend, that boundary does not exist. What you have introduced is a network protocol between two modules that could talk through a function call.

Cases where it is overkill

One tool and one consumer. If you expose a single operation and only your agent uses it, a function with its docstring does the same job with no transport in between.
Deterministic flow. When your code, not the model, decides the order of the steps, you do not need it to pick a tool: you need a script.
Data you already have. If the content fits in the prompt and does not change during the session, injecting it is cheaper and more predictable than a call.
Latency sensitivity. Every hop adds serialisation, a round trip and a model decision. In end user interaction that shows.
Bloated tool surface. The cost is not only the token. The more similar tools the model sees, the worse it chooses between them.

That last point is the one we run into most in audits: teams with five MCP servers connected, forty tools visible in the prompt and an agent that confuses two tools with nearly identical names.

When it does pay off

The article is not a case against MCP, and we would not sign one either. The protocol wins as soon as any of these conditions shows up:

Several different clients consume the same tools and you do not want to reimplement them in each one.
The catalogue changes more often than the agent and you want to ship them separately.
There is delegated authentication involved, with OAuth and credentials that should never pass through the prompt.
* You distribute to third parties: someone installs your server without seeing your code.

In the Claude Code ecosystem there is also a practical factor the article does not cover. Skills, subagents and hooks solve a good part of what people end up building as a server. A skill packages instructions and context and takes up no context window until it is invoked. A PostToolUse hook validates a write without exposing anything to the model. A subagent isolates a long task without polluting the main conversation. Before opening a new repository for a server, it is worth ruling those three out first.

The five minute question

It is not whether MCP is cool. It is this: who else is going to call this tool and who is going to deploy it? If both answers are the same person in the same place, write the function. If either one includes somebody you do not control, build the server. And a second question, just as cheap: does the model need to choose? MCP exists so that an LLM can decide between options with enough information. If the choice is already made in your code, the protocol only adds ceremony.

Our position after a fair number of integrations is that MCP is infrastructure, and infrastructure is justified by reuse, not by elegance. When a client asks us for a server, the first half hour goes into checking whether what they need is a server or a well documented function.