Français
Deutsch
A paradigm question, not a technology question
When IT teams discover MCP, the question invariably arises: "Why not simply expose our existing REST APIs?" It's a legitimate question. The answer illuminates a fundamental design difference.
REST API: designed for machines
A standard REST API exposes endpoints with well-defined conventions. It's designed to be consumed by code: a developer writes a client that calls GET /projects/{id}/tickets, parses the JSON, and processes the data.
The problem: for an LLM to use a REST API, it must understand its documentation (often incomplete), manage authentication, parse responses, handle errors. This requires an adaptation layer — either custom code or a complex prompt describing the API.
MCP: designed for LLMs
MCP is an abstraction layer over existing APIs, optimised for LLM consumption. Its distinguishing characteristics:
| Dimension | REST API | MCP Server |
|---|---|---|
| Discovery | External documentation (Swagger, Postman) | Native introspection (list_tools) |
| Tool description | Technical (endpoint, HTTP parameters) | Semantic (natural language description) |
| Error handling | Standard HTTP codes | Structured errors with context |
| Security | OAuth, API keys, JWT | Process isolation + MCP permissions |
When REST API remains preferable
MCP is not a universal answer. REST remains preferable when:
- The consumer is code (not an LLM)
- Performance is critical (MCP adds a latency layer)
- You need to expose the API to external partners
- Your industry's REST standardisation matters
Recommended hybrid architecture
For most organisations, the right approach is to maintain REST APIs for machine-to-machine integrations while adding an MCP Server layer for LLM integrations. The MCP server consumes your existing REST APIs — it doesn't replace them, it adapts them for AI agents.
"MCP and REST are not competitors. MCP is a translator that makes your REST APIs understandable to AI agents."