At a glance
| Regular API (e.g. REST) | MCP | |
|---|---|---|
| Audience | Developers writing code | AI applications (and the models inside them) |
| Defines | Endpoints and data for one service | A common protocol for tools, resources, prompts across services |
| Discovery | Docs or a spec (e.g. OpenAPI) read by a developer | Built in: clients ask the server what it offers |
| Integration effort | Custom code per service and per application | Write a server once; any compatible client can use it |
| Relationship | Underlying capability | Often a layer over APIs |
| Typical consumer decisions | Programmer chooses calls | Model chooses tools, host/user approves |
Saying "MCP vs API" is a little like asking "USB vs a keyboard": one is the standard connection, the other is the thing you connect.
What is each?
An API (application programming interface) is how software talks to a service: send a request to an endpoint, get a response. REST, GraphQL and gRPC are common styles. APIs are designed for developers who read documentation and write code against them.
MCP (What is MCP (Model Context Protocol)?) is a protocol that lets AI applications connect to external capabilities uniformly. An MCP server exposes tools, resources and prompts with machine-readable descriptions, so a model can see what is available and how to call it.
Key differences
Who is the consumer? APIs assume a programmer who decides in advance which endpoint to call. MCP assumes a model will decide at run time, so tool descriptions, schemas and results are written for it.
Granularity. A REST API may have hundreds of endpoints shaped around a data model. A good MCP server exposes a small number of task-oriented tools ("find a customer's open invoices") because too many low-level tools confuse models and waste context.
Statefulness. MCP sessions begin with a handshake where both sides declare capabilities; typical REST calls are stateless requests.
Discovery. With an API, a developer reads docs. With MCP, the client calls tools/list and learns the tools programmatically.
Security. An API key protects the API. With MCP you additionally need to think about which tools the model may invoke, user consent in the host, and untrusted content in tool results (What is Prompt Injection?).
When to choose which
- You are building a service for developers → publish an API. Optionally add an MCP server that wraps it for AI clients.
- You want your service usable from many AI apps → an MCP server is worth building.
- You are building one AI application with a few internal functions → direct Function Calling (Tool Calling) Explained against your own code or API is probably simpler (Function Calling vs MCP).
- You are consuming a third-party capability in an AI app → look for an existing, trusted MCP server before writing a custom integration, but review what it can access.
Example
A project-management SaaS has a REST API with endpoints for projects, tasks, comments and users. Its MCP server offers four tools: search_tasks, create_task, add_comment, list_my_work. Each tool internally calls several REST endpoints, applies the signed-in user's permissions, and returns a compact summary. The REST API still exists for everything else; MCP is a tailored AI-facing front door.
Common mistakes
- Believing MCP makes APIs obsolete.
- Auto-generating one MCP tool per API endpoint, which floods the model with choices.
- Forgetting that the MCP server still needs authentication and authorisation against the underlying API.
- Treating MCP as inherently secure; it standardises access, it does not decide what should be accessible.