Overview
MCP does not replace APIs; it usually wraps them. A REST or gRPC API is designed for developers who read documentation and write code against fixed endpoints. MCP is designed for AI applications that discover capabilities at runtime. An MCP server describes its tools in a machine-readable way, so a model can decide which to call and with what arguments without custom glue code.
The practical differences are about audience and lifecycle. APIs are integrated at build time, versioned, and called by deterministic code. MCP tools are discovered at connection time, chosen by a model, and often shaped around tasks rather than resources: "search_customer_tickets" instead of "GET /tickets?customer_id=". Many MCP servers are thin layers over existing APIs that add descriptions, task-friendly inputs, and safe defaults.
An API is a detailed service manual for technicians who already know what they want. MCP is a concierge desk that tells any visitor what services are available and in plain terms what each one does, then handles the request. The concierge still uses the same back-office systems behind the scenes.
When to use it
- Deciding whether to expose a service to AI agents via MCP, a direct API, or both.
- Explaining how AI integrations differ from traditional integrations.
- Designing task-oriented tools on top of existing APIs.
Where it shows up in interviews
Recognize it when: existing APIs need to be usable by agents.
- Design AI Agent Platform
- Design an AI customer-support system
Where it is used in real software
Many vendors keep their public REST API and add an MCP server so AI assistants can use the same capabilities.
Teams wrap several internal APIs into one task-focused MCP server for support agents.
Key terms
- API
- A contract of endpoints, inputs, and outputs that programs call directly.
- Runtime discovery
- Learning available capabilities when connecting, rather than at build time.
- Task-oriented tool
- A tool shaped around a user goal, often combining several API calls.
- Tool description
- Natural-language text and schema the model reads to decide when to use a tool.
How it works, step by step
- 1Start from the API
Identify the endpoints that support common user tasks.
- 2Design tasks, not endpoints
Group calls into tools that match what users ask for, with simple inputs.
- 3Describe clearly
Write names, descriptions, and schemas the model can understand.
- 4Add safety
Enforce auth, limits, and confirmations in the server rather than trusting the model.
- 5Keep the API for code
Deterministic services and partners continue to call the API directly.
STEP 1Code calls fixed endpoints it was written against, such as GET /orders/4821.
Comparison
Exposing an order system.
| Aspect | API | MCP |
|---|---|---|
| Primary user | Developers writing code | AI applications and models |
| Discovery | Docs and OpenAPI at build time | tools/list at runtime |
| Granularity | Resources and endpoints | User tasks |
| Who decides calls | Program logic | The model with host approval |
| Transport | HTTP or gRPC | JSON-RPC over stdio or HTTP |
NOWAspect: Primary user | API: Developers writing code | MCP: AI applications and models
Keep the API as the system contract and add MCP as an AI-friendly layer on top.
Implementation
// Existing REST API clientasync function getOrder(id: string) { return (await fetch(`${API}/orders/${id}`, { headers: auth() })).json(); }async function listShipments(orderId: string) { return (await fetch(`${API}/orders/${orderId}/shipments`, { headers: auth() })).json(); } // MCP tool: one task-level action that combines two API callsserver.tool( "track_order", "Get an order's status and latest shipment location for a customer question like 'where is my order?'", { orderId: z.string() }, async ({ orderId }) => { const [order, shipments] = await Promise.all([getOrder(orderId), listShipments(orderId)]); const latest = shipments.at(-1); return { content: [{ type: "text", text: `Status ${order.status}. Last scan ${latest?.location ?? "none"}.` }] }; },);Complexity and performance
Negligible next to model latency.
Too many tools make model selection worse.
Trade-offs
Mirroring every endpoint as a tool overwhelms the model. A handful of task-shaped tools is more reliable.
Let the model choose among tools, but keep business rules and authorization in server code.
Variants and related techniques
Auto-generate tools from an API spec, a quick start that usually needs curation.
Common mistakes
- Exposing every API endpoint as a tool.
Fix: Curate a small set of task-focused tools with clear descriptions.
- Relying on the model to enforce permissions.
Fix: Authorize every call in the server using the user's identity.
Interview questions
Does MCP replace REST APIs?
No. APIs remain the contract for programs and partners. MCP is a layer that makes capabilities discoverable and usable by AI applications, and MCP servers usually call existing APIs.
How would you design MCP tools for an existing API with 80 endpoints?
Identify the top user tasks, create a small number of tools that each combine the needed calls, give them clear descriptions and simple schemas, enforce auth and limits server-side, and evaluate tool selection with real prompts.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Wrap two REST endpoints into one task-level MCP tool | Easy | Task design. |
| Design the MCP layer for a large internal API | Medium | Tool curation and security. |