MCP server vs API: when the wrapper is just overhead

Automation Engineering · By Caleb Sakala · June 18, 2026

A tiny deadpan cardboard box buried under a towering mountain of ribbons, bubble wrap and packing peanuts at a post office counter

The phrase "mcp server vs api" sets up a fight that does not exist. An MCP server is not a rival to your API. It is a thin layer that sits on top of one and describes it so a language model can read the menu while it runs. Picking between the two is rarely the real choice. What actually decides it is whether the thing calling your service already knows what it wants, or has to find out first.

Get that one question right and the rest falls out of it, including the part nobody mentions: discovery is not free, and on a deterministic automation you can pay for it thousands of times a day with nothing to show for it.

What an MCP server wraps

Anthropic open-sourced the Model Context Protocol on November 25, 2024 to kill the N×M integration problem, where every AI app needs a custom connector for every tool it touches. An MCP server speaks JSON-RPC 2.0 and exposes a tools/list call, so a client can ask what operations exist and get back each tool's name and its full input schema while it runs. Underneath that interface, the server usually calls the same REST endpoints you already ship. Codecademy's breakdown says it without hedging: MCP servers often use REST APIs underneath. The protocol stays transport-agnostic, running over stdio for local processes or Streamable HTTP for remote ones, the latter added in the 2025-03-26 spec revision to replace the original HTTP+SSE design.

So "should this be an API or an MCP server" usually means "should you expose an existing API through a discovery layer." That reframes the decision into something you can answer.

Does the caller already know what it needs?

A direct API call assumes the caller knows the endpoint, the method, and the payload before anything runs. A developer writing an integration knows all three. A nightly job that posts yesterday's orders to a billing service knows all three. Neither needs to ask a server what it can do, because that was settled when the code was written.

An MCP server assumes the reverse. It assumes the caller cannot name the tool it needs yet and has to read the options first. That is the exact situation a general-purpose agent lives in, and it is the situation almost no scheduled automation is in.

Walk the same operation through both paths. Say a workflow needs to refund order 4471. As a direct call, that is one line written once: a POST to /refunds carrying the order id and an amount, run unchanged on every invoice that qualifies. As an MCP tool call, the model first pulls the server's tool list, reads the refund tool's schema, maps the request onto that tool, fills in the arguments, and only then fires the same POST underneath. When a fixed script already knew it wanted a refund, every step before the POST was wasted motion. When a model had to decide between issuing a refund and replacing the item based on a messy support thread, those same steps were the actual work.

The token cost of asking what's possible

The cost of that menu is not theoretical. Every tool an MCP server exposes ships its full schema into the model's context on each turn, whether the tool gets used or not. An open issue on the official MCP repository, #2808, puts the overhead at roughly 1,000 tokens per tool per session and argues the spec should address it. Stack a few servers together and it compounds fast: a setup spanning three servers and dozens of tools can park tens of thousands of tokens in context before the agent has read one word from the user. Anthropic conceded the problem in its November 2025 engineering write-up on code execution with MCP, an approach built specifically to stop loading every definition up front.

The bill scales with how many services you bolt on. Public reports of multi-server setups describe dozens of tool definitions parking tens of thousands of tokens in context before any real work begins, and at typical input pricing that overhead repeats on every call. Run the automation on a schedule, a thousand times a day, and you pay for the same unused menu a thousand times over.

Put that against a fixed workflow and the waste is hard to miss. A job that always hits the same two endpoints, wrapped in a server exposing forty tools, makes the model re-read thirty-eight tools it will never call, on every run. A plain HTTP request reads none of them.

When the discovery layer earns its keep

None of this is a case against MCP. When the caller is a real agent choosing tools mid-conversation, runtime discovery is the whole point. A support agent that might check an order, issue a refund, or escalate to a human, depending on what the customer says, benefits from seeing all of its options before it decides. The portability is real too: one client can reach fifty services through a single protocol instead of fifty hand-written SDKs, and you can add or drop a server without redeploying the client. That is why the community shipped thousands of servers in MCP's first year.

The pattern shows up cleanly in workflow design. Picture an invoice-intake automation that pulls a PDF, extracts the line items, and posts them to your accounting system. The posting step knows its endpoint cold, so in a Chase Agents automation you wire it as a direct API request and it runs without dragging unrelated tool schemas into context, while the MCP server connection stays reserved for the one step that has to reach an unpredictable set of services.

What going direct costs you

Hard-coding sends its own bill, paid later. The day your service adds an endpoint, every direct caller has to be updated and shipped again, because none of them asked what was possible, they were told once and never checked back. An MCP client picks up the new tool on its next tools/list call with no redeploy. For a stable internal API that changes a few times a year, that tradeoff favors the direct call by a mile. For a fast-moving surface where new tools land most weeks, the discovery layer starts earning its rent. The honest version of this decision weighs how often your surface changes against how much context budget you can spare, rather than which option sounds more modern.

A four-question rule

Most cases settle with four questions:

  • Does the caller know the exact operation before runtime? If yes, call the API directly and skip the wrapper.
  • Is the caller a language model picking tools from context it does not have until it runs? If yes, MCP's discovery is doing real work.
  • Are you pointing one client at many services that change often? MCP's single protocol beats maintaining a pile of SDKs.
  • Is the call on a hot path where latency and token budget are tight? Go direct, because the discovery round trip buys you nothing there.

This is also where authorization gets cleaner. Action-type routing lets a research step in a Chase Agents automation return purchase_recommendation objects that route to a separate approval step, while only the orchestrator holds the MCP tool access needed to place an order. Deterministic steps issue fixed calls while the single step that must choose among tools gets the discovery layer, so tool permissions stay scoped at the workflow level instead of every step inheriting them.

Before you stand up an MCP server for your own API, count the tools the caller will touch on a typical run. If that number is small and known ahead of time, you are about to charge yourself a discovery tax on a menu nobody reads. Wrap a service in MCP when something on the other end genuinely has to ask what is possible. Hard-code the call when it already knows.