Ask a room of engineers whether they should "use MCP or REST" for their agent and you'll get a religious argument. It is the wrong fight. The honest answer, backed by the first large empirical look at what shipped MCP servers actually are, is that the two are not alternatives at all — most MCP servers are REST APIs, wearing a thin coat.
A July 2025 study of 116 official MCP servers found that 88.6% are REST-backed, and 92% implement their tools as bare wrappers over an existing HTTP endpoint. The protocol is not a new way to move bytes. It's a new way to present the bytes you already move. So the question "MCP vs REST" mostly dissolves: under the hood it's REST either way. What changes is who the interface is for, and how much of it you hand over.
The real variable is who's reading the menu#
A REST API is written for a developer who reads the docs once, at build time, and writes deterministic code against them. MCP is written for a model that has to figure out the integration at run time, from the tool list alone, every single call. That difference — build-time human vs. run-time probabilistic reader — is the whole story. WorkOS frames it well: REST exposes endpoints; MCP exposes capabilities an agent can discover and reason about without a human in the loop.
That reframing kills two bad instincts at once. The first is "MCP is faster/better, migrate everything." There is nothing to migrate — your REST API keeps serving your web app, your mobile client, and your partners, untouched. The second is more seductive: "I have an OpenAPI spec, I'll just generate an MCP server from it and expose the lot." That one is a trap, and it's the most common mistake teams make.
Curation is the protocol's actual value#
Here is the number that should change how you think about this. Across the servers studied, the median MCP server exposes just 19% of its API's available operations. Not because the tooling is immature — because exposing more makes the agent worse.
Speakeasy, which has built 50+ production MCP servers, calls the anti-pattern "tool explosion": a 200-endpoint OpenAPI document naively becomes ~200 tools, each with a verbose description, and the agent now spends its context window reading a menu instead of doing the work. Health checks, admin routes, the seventeenth variant of a list endpoint — every one you add is another way for the model to pick wrong. The same study's automated pipeline, AutoMCP, lifted the share of working generated tools from 76% to 94.2% with spec repair — but the move that mattered most for quality was the opposite of generation: filtering and regrouping cut the median tool count per API by a third.
MCP's value isn't the wire format. It's the 19% of your API you have the discipline not to expose.
Read that back through the wrapper statistic and the picture sharpens. Wrapping is easy; the machine does it. The engineering — the part that determines whether your agent is reliable — is deciding which operations an agent should ever see, merging three endpoints into one task-shaped tool, and writing a description that reads like an instruction rather than a schema dump. That is product work, not plumbing, and it's exactly the work auto-generation skips.
So when do you actually need it?#
If you are building one first-party agent against a backend you control, you very likely don't need MCP yet. Hand the model your existing endpoints as function/tool definitions — the OpenAI Agents SDK and every other framework will take an OpenAPI spec directly — prune it to the operations the agent needs, and you've captured most of the benefit with none of the extra server to run. MCP in a closed single-consumer loop is a standard solving a coordination problem you don't have.
MCP starts paying for itself when one of three things is true:
- Many independent consumers. Several agents, or third-party clients you don't control, need the same tools. Now a shared, specified interface beats every team re-deriving your API by hand.
- Runtime discovery. The available tools change based on who's connected, what's installed, or what the user authorized — and the agent must learn them at call time, not from a doc.
- A host that needs a seam. You want a uniform place to slot consent prompts, auth, rate limits, and UI around every tool call, regardless of which underlying API it hits. That governance layer is what the protocol gives you that a pile of REST endpoints does not.
None of those is about speed or elegance. They're about coordination across boundaries — which is the only thing a protocol is ever really for.
So drop the versus. Your API stays REST. The question worth arguing about is the one the data already answered: not which interface, but how little of it to expose, and whether anyone besides your own agent is going to read it.
