Building something agentic means hitting this decision within the first week: connect a REST API the model can call, or expose an MCP server. Most explanations stop at "MCP is for tools, REST is for services", which does not help anyone choose. This one goes further.
The structural difference
A REST API has fixed, known endpoints. The client, here an LLM-driven agent, needs the request and response shape ahead of time, usually through an OpenAPI spec translated into a tool definition. A new capability means a new endpoint and an updated spec.
MCP inverts that. The server exposes list_tools and tells the model at runtime what it can do and which parameters each action takes. No capability has to be baked into the client, and the schema is written for a model rather than adapted from a human-facing API.
Sessions differ too. MCP carries persistent, stateful sessions over stdio or SSE. REST stays stateless, and the client handles session state itself through tokens or cookies.
Where REST wins
- Maturity. Two decades of auth standards, caching layers, rate limiting, monitoring, and documentation conventions. MCP has a fraction of that history.
- Non-agentic consumers. Web frontends, mobile apps, and internal services all speak REST. An MCP-only build leaves you maintaining a second interface.
- Small fixed surfaces. Three endpoints that never change gain nothing from runtime discovery, and a static OpenAPI spec is easier to test and secure.
- Infrastructure support. Cloud providers, frameworks, and load balancers understand REST without configuration. MCP hosting patterns are still settling.
Where MCP wins
- Runtime discovery. Plugins, user-installed extensions, and evolving toolsets change what is available. Discovery avoids the redeploy cycle.
- Model-native schemas. Tool definitions are read by a model directly, which removes the wrapper that turns OpenAPI into a function-calling schema.
- Consistency across vendors. An agent connected to several MCP servers gets one interaction pattern. Several independently designed REST APIs mean several auth schemes, error formats, and pagination styles.
- Stateful tool use. A server that remembers context across calls in a session is native to MCP. REST needs session code written on top.
A worked example
You are building an agent that triages support tickets. It reads ticket details, searches a knowledge base, and occasionally creates a follow-up task in a project tool.
Ticket reads and knowledge base search are stable operations the whole team already depends on. Keep them on REST. The endpoints exist, they are documented, and other parts of the product call them.
Creating a follow-up task means calling a third-party project tool where the available actions expand over time: comment, reprioritize, assign, and whatever ships next quarter. That belongs on MCP. You get discovery of whatever the tool exposes without writing a wrapper per action.
The agent's reasoning loop benefits from MCP's session awareness, since it may need something it looked up two calls ago without your code threading that state through.
Nothing migrated wholesale in that example. Stable infrastructure stayed on REST. The agent-facing, changing surface went to MCP.
Migrating without a rewrite
If a REST API already exists, put a thin MCP server in front of it. Translate list_tools and call_tool into calls against the endpoints you have. The agent gets discovery and model-native schemas, your business logic and auth stay in one place, and the web and mobile clients notice nothing.
You maintain a translation layer. That costs less than rebuilding core services, and far less than running two full interfaces.
Four things to check before committing
- Security. MCP's permission and vetting ecosystem has not caught up with the access a typical server receives. REST auth patterns are better understood. Vet an MCP server the way you vet a new dependency.
- Implementation quality. Server quality varies widely on a young spec. A popular server is not automatically a careful one.
- Latency by transport. A local stdio server can beat a network call. Remote SSE servers bring their own profile, so benchmark rather than assume.
- Debugging. curl, Postman, and browser devtools have covered REST for years. MCP tooling is thinner.
What the numbers say
TrueFoundry's benchmarks put Streamable HTTP, MCP's current remote transport, at roughly 10ms per call under load, holding 290 to 300 requests per second at full success in a shared-session deployment. The older SSE transport dropped to 7 to 30 requests per second under the same load with latency in the hundreds of milliseconds, which is why Streamable HTTP replaced it in the spec.
Library bugs can outweigh all of that. A 2026 benchmark traced about 40ms of fixed overhead on every HTTP tool call to rmcp v0.16, a Rust MCP library that hardcoded SSE-style framing for stateless replies that should have returned plain JSON. That inflated latency roughly 35 times over the tool's actual I/O time. It was fixed in v0.17.0.
A slow MCP server may be measuring the protocol or one library's bug. Only your own benchmark separates the two.
The short version
Default to REST for stable, high-traffic operations with consumers beyond the agent. Use MCP at the tool-calling boundary where capabilities change at runtime. Keep core services on REST and build the agent-facing layer on MCP.
The full breakdown, including transport benchmarks and sources: https://www.hamvero.space/blog/mcp-vs-rest-apis-agentic-tools/
Top comments (0)