When Should You Not Build an MCP Server? AI Engineer Interview Question Explained

In the field of AI engineering, MCP (Model Context Protocol) has become an important protocol for connecting large models with external tools. But a question worth pondering is: when should you NOT build an MCP server? This seemingly counterintuitive interview question precisely tests an engineer's understanding of technical boundaries.

Core Principle: Single Function Calls in the Same Process Don't Need MCP

If an application is just calling a function within the same process, writing a plain function is far simpler than setting up an MCP server. MCP introduces an extra layer of abstraction, network communication overhead, and protocol complexity — all of which have zero value in a single-process, single-function scenario.

This also reveals a common misconception: not all tool integrations require MCP. The first principle of technology selection is matching actual needs, not chasing popular protocols.

Where MCP Truly Shines: Shared Tools Across Multiple Clients and Teams

MCP was designed to solve the problem of tool reuse and standardization. It only delivers real value when multiple clients (such as different AI applications, IDE plugins, chat interfaces) or multiple teams need to access the same set of tools.

The benefits MCP brings in this case include:

• A unified standard for tool interfaces
• Cross-team tool reuse
• Tool maintenance independent of any client

In other words, MCP's core value lies in decoupling — separating tool providers from tool consumers. If this decoupling need doesn't exist, MCP is over-engineering.

MCP (Model Context Protocol) was open-sourced by Anthropic in late 2024, using JSON-RPC 2.0 as its communication protocol. It defines three core primitives: Tools (callable functions), Resources (readable data sources), and Prompts (preset prompt templates). Architecturally, MCP adopts a client-server model where a Host (such as Claude Desktop or Cursor) embeds an MCP Client, communicating with an MCP Server through transport layers like stdio or SSE. This design completely decouples tool providers from consumers: a Server only needs to implement the protocol interface once, and any MCP-compatible Host can call it plug-and-play. Precisely because of this, MCP's value only truly emerges in "one-to-many" scenarios — if there's only one consumer, the standardization benefit is zero, and you instead bear the burden of maintaining the transport layer and handling handshakes and error codes. Understanding MCP's protocol positioning is the prerequisite for judging whether you need it.

Hidden Cost: Every Tool Consumes Context Tokens

This is a key point many engineers overlook: every tool you expose consumes context tokens on every request. Tool definitions, parameter descriptions, return value formats — all of this information needs to be stuffed into the model's context.

The more tools there are, the more context they occupy, leaving less room for actual task reasoning. This not only increases costs but may also directly degrade model performance.

The context window refers to the maximum number of tokens a large model can process in a single inference (e.g., 128K, 200K). On every request, the system prompt, tool definitions, conversation history, and user input all share this budget. A single MCP tool's JSON Schema description — including name, purpose, parameter types and constraints — typically consumes 50 to 200 tokens; 50 tools could take up 5,000 to 10,000 tokens. This brings a double cost: first, API costs that scale linearly with token usage; second, the "context dilution" effect — research shows that when irrelevant information occupies a large portion of the context, the model's attention weight on key information decreases, and reasoning accuracy drops significantly. This phenomenon is known in long-context research as "lost in the middle" — the model's recall of information in the middle of the context is noticeably lower than at the beginning and end. Therefore, streamlining your tool set isn't just cost optimization — it's performance optimization.

The Counterintuitive Truth: A Server with 50 Tools Can Make the Model Worse

Many people's intuition is "more tools, more capability." But reality is the opposite — an MCP server containing 50 tools can make the model perform worse, not better.

The reasons:

1. Choice overload: The model needs to pick the right one from a large number of tools, increasing the probability of error
2. Context dilution: Massive tool definitions squeeze out the token budget that should be used for reasoning
3. Attention dispersion: The presence of irrelevant tools interferes with the model's focus on the current task

Therefore, tool set design should pursue precision and restraint, not sheer quantity.

Tool selection is essentially a "function calling" decision task, where the model needs to match the most suitable tool from a candidate set based on user intent. The larger the candidate set, the larger the decision space, and the higher the probability of the model misselecting, missing, or fabricating parameters. This is similar to a human ordering at a restaurant with an overly long menu — the more options, the worse the decision quality. Common mitigation strategies in the industry include: tool grouping and namespace isolation (e.g., github.create_issue), hierarchical routing (first let the model choose a category, then a specific tool), and dynamic tool loading (only injecting relevant tools based on conversation context). The common thread of all these approaches is "narrowing the candidate set." So rather than building an all-encompassing MCP server, it's better to split into multiple small servers by domain, letting the Host connect on demand.

For Fixed Workflows, Write Code — Don't Let the Model Choose

If a set of steps is always in the same order, just hard-code the workflow. Having the model "choose" what to do next every time is wasteful — it wastes tokens and introduces unnecessary uncertainty.

The model's strength lies in handling tasks that are non-deterministic and require judgment. For deterministic processes, traditional code is more reliable, more economical, and easier to debug.

Interview Trap: Always Answering "Always Needed" Is the Wrong Answer

The biggest trap in this interview question is answering "always." A strong answer should be able to clearly identify a scenario where you would say "no."

What this really tests is an engineer's judgment:

• Whether they understand the boundaries of technology selection
• Whether they have cost awareness
• Whether they can resist the temptation of "new protocol worship"

In AI engineering practice, knowing when not to use a technology is often more important than knowing how to use it. MCP is a powerful tool, but powerful tools need to be used in the right scenarios.

Background Notes

In technology selection, distinguishing between "deterministic workflows" and "agentic workflows" is a key judgment framework. A deterministic workflow refers to a process where steps, branches, and outcomes can all be pre-enumerated — for example, "pull data → transform format → write to database." Such tasks can be orchestrated with traditional code, which is reliable and incurs zero token overhead. An agentic workflow involves open-ended judgment — for example, "decide which API to call based on vague user requirements and handle exceptions." Only here is the model's language understanding and reasoning ability irreplaceable. A common anti-pattern in practice is: handing a process that could be hard-coded to the model for "decision-making," resulting in unstable execution results, difficult debugging, and high costs. The correct approach is hybrid orchestration — use code for the deterministic skeleton, and only introduce the model at nodes that truly require judgment. This principle applies not only to MCP but is a fundamental skill across all of AI engineering.

One-line Summary

MCP isn't a silver bullet — you shouldn't build an MCP server for single-process single-function calls, fixed workflows, or tool hoarding scenarios.

Paragraph Summary

The article revolves around the interview question "when should you not build an MCP server," with the core idea that technology selection should match actual needs rather than chase popular protocols. MCP's real value lies in decoupling and standardization when multiple clients or teams share the same set of tools, whereas in single-process single-function call scenarios, a plain function is simpler and more direct. The article particularly emphasizes hidden costs: every exposed tool consumes context tokens on every request, and a server with 50 tools can degrade model performance through choice overload, context dilution, and attention dispersion. For fixed-sequence workflows, you should implement them directly in code rather than having the model choose each time. Answering "always needed" in an interview is a trap — a strong answer should clearly identify scenarios where it shouldn't be used, demonstrating an engineer's judgment and cost awareness.