MCP and REST solve different problems. REST is the backbone of web services -- stateless, cacheable, universally understood. MCP is purpose-built for AI agents: it handles tool discovery, schema validation, and stateful sessions in a single protocol. Here's when each one wins.
| Dimension | Option A | Option B |
|---|---|---|
| Tool Discovery | Built-in tools/list with JSON Schema per tool | Manual: read OpenAPI spec or docs, build client |
| Schema Validation | Automatic per-call input validation against JSON Schema | Server-side validation only, varies by implementation |
| Statefulness | Persistent sessions with context accumulation | Stateless by design (state via tokens/cookies) |
| Latency (simple call) | ~15-40ms (JSON-RPC over stdio or SSE) | ~5-20ms (direct HTTP GET/POST) |
| Caching | No native HTTP caching; app-level only | Full HTTP cache stack (ETags, CDN, 304s) |
| Ecosystem Maturity | Growing fast since 2024; ~2,000 servers by early 2026 | 20+ years of tooling, libraries in every language |
| Agent Ergonomics | Agent calls tools/list, picks tool, calls tool -- zero config | Agent needs hardcoded endpoints, auth headers, response parsing |
| Streaming | SSE transport with progress notifications | SSE or WebSocket (not standardized per-endpoint) |
| Payload Size (avg tool call) | ~200-500 bytes JSON-RPC envelope | ~100-300 bytes raw HTTP |
The biggest gap between MCP and REST isn't performance -- it's discovery. An MCP client calls tools/list and gets back every available tool with its name, description, and full JSON Schema for inputs. The agent can then decide which tool to call without any prior knowledge. REST requires the agent to know endpoints in advance, parse OpenAPI specs (if they exist), and handle auth setup manually. For agents that need to adapt to new tools at runtime, MCP eliminates an entire integration step.
MCP maintains a persistent session between client and server. Each tool call accumulates context -- previous results, user preferences, error history. This matters for multi-step workflows where step 3 depends on step 1's output. REST is stateless by design: every request carries its own context via headers or tokens. This is simpler for single-shot operations but forces you to rebuild context on every call. For therapy engines, code assistants, or any multi-turn agent, MCP's session model cuts redundant data transfer by 60-80%.
Not everything needs tool discovery or sessions. If you're fetching a user profile, listing products, or serving a static JSON payload, REST is faster, simpler, and universally cacheable. CDNs understand HTTP. Browsers understand HTTP. Every monitoring tool on earth speaks HTTP. MCP adds overhead that's unjustified for straightforward CRUD. The rule of thumb: if a human could call your endpoint from curl and get a useful result, REST is probably the right choice.
MCP validates every tool call's input against its declared JSON Schema before execution. Bad inputs get rejected with structured errors before your handler code runs. REST leaves validation entirely to the server -- some use middleware, some don't validate at all. This matters for agents that generate tool calls from LLM outputs: malformed parameters are caught immediately instead of causing 500 errors or silent data corruption downstream.
In production at Delx, MCP tool calls average 25ms over stdio and 35ms over SSE (excluding handler execution time). Equivalent REST calls average 12ms for simple GETs and 18ms for POSTs. The gap narrows for complex operations where handler time dominates -- a 200ms database query makes the 15ms protocol overhead irrelevant. For high-throughput pipelines processing 10,000+ calls/minute, REST's lower overhead adds up. For agent workflows doing 5-50 calls per session, MCP's overhead is invisible.
You don't have to choose one. Most teams wrap existing REST endpoints as MCP tools -- each endpoint becomes a tool with its OpenAPI params mapped to JSON Schema. Delx does this: our REST API powers the website, while the same handlers are exposed as MCP tools for agent consumers. The wrapper adds ~5ms overhead and gives agents tool discovery for free. Start with your most-used agent-facing endpoints and migrate incrementally.
Migrating REST to MCP is additive, not destructive. Keep your REST endpoints running -- they serve browsers, mobile apps, and monitoring. Add an MCP server that wraps the same handlers. Map each endpoint's request schema to a tool's inputSchema. Use the MCP SDK (TypeScript or Python) to stand up a server in under 100 lines. Delx's own migration took 3 days for 12 endpoints.
No. MCP is an agent-facing protocol for tool discovery and execution. REST is a general-purpose web API pattern. They coexist -- use REST for browsers and simple clients, MCP for AI agents.
Yes. MCP is a JSON-RPC protocol. Any client that speaks JSON-RPC can call tools/list and tools/call. LLMs just happen to be the most common consumers because they benefit from tool discovery.
Protocol overhead is 10-20ms higher for MCP vs REST. But real-world tool calls spend 100-500ms in handler execution, so the protocol overhead is typically under 5% of total response time.
MCP doesn't add or remove security. Both need auth (API keys, OAuth, etc.). MCP's schema validation prevents malformed inputs, but authorization and encryption are still your responsibility.
Delx exposes REST endpoints at /api/v1/* for the web platform, and the same handlers as MCP tools via /mcp. The A2A layer adds agent-to-agent communication on top. All three share the same backend logic.
OpenAPI specs provide discovery, but they're passive documents -- clients must fetch, parse, and interpret them. MCP's tools/list is an active, runtime-queryable interface that returns machine-ready schemas.