API vs MCP: Which One Wins When Agents Need Tools?
REST is a direct call to one service. MCP is a standard protocol that lets AI agents discover and use any compliant tool. Here’s how they differ, when to pick which, and the one-liner that wins the interview.
Explain it like I’m five
Imagine you have a robot butler. You want it to order pizza, check the weather, and water your plants. The old way — the API way — is like giving the butler a stack of phone books: the pizza place has its own number and you must speak its exact ordering words, the weather station has a different number and different words, the plant-watering company yet another. Every service, its own secret language, and you wrote all of it down by hand.
The MCP way is like giving the butler a universal remote with one big button that says “ask what you can do.” The butler points it at the pizza oven, and the oven introduces itself: “I can bake, here are my buttons, here’s what each button needs.” No phone books. The butler learns every gadget on the spot — and the same remote works in every house. This guide is the grown-up version of that remote: what the protocol actually standardizes, where it beats plain APIs, and where the plain API still wins.
Intuition: phone books vs a universal remote
REST is the phone-book approach you already know. Your app needs data, so it calls an HTTP endpoint: GET /users/42, the server answers JSON, done. It’s simple, stateless — every request stands alone — and it works beautifully when a human wrote the integration. But every service brings its own docs, its own schemas, its own auth keys. Fifty services, fifty bespoke wirings.
MCP — the Model Context Protocol — is the universal remote. Released by Anthropic in November 2024 and now a Linux Foundation standard, it’s an open protocol for connecting AI models and agents to external data and tools. The pitch, in Anthropic’s own framing, is “USB-C for AI apps”: one standard plug, and any compliant tool fits. Instead of the agent learning fifty private dialects, every tool speaks one protocol — and the agent discovers what each tool can do at runtime instead of having it hardcoded.
The whole design has three jobs. Standardize the handshake: host, client, and server roles so any pairing works without custom glue. Advertise capabilities: servers announce their tools, data, and templates with machine-readable schemas. Keep the session alive: a stateful connection where the agent and tool remember context across calls. Nail those three and the agent’s tool belt becomes plug-and-play.
How it works: hosts, clients, and servers
The three roles. The host is the AI application — Claude Desktop, Cursor, your agent runtime. It owns the conversation, the model, and the security policy. Inside the host, there is one client per tool — a small connector that maintains a 1:1 connection to exactly one server. The server is the tool itself: a separate process, local or remote, that exposes capabilities. Connect to ten tools and the host runs ten clients; the host code itself never changes. The isolation is deliberate — servers never see the whole conversation and can’t see each other; the host aggregates context and enforces the boundaries.
What servers expose. Three primitives, split by who controls them. Tools are model-controlled: executable actions with JSON Schema inputs — send a message, run a query, create a record. Resources are application-controlled: data the host injects as context — files, database rows, documents — addressed by URI. Prompts are user-controlled: reusable templates the user picks explicitly, like slash commands. Tools are the write side, resources the read side, prompts the steering wheel.
The session lifecycle. Messages are JSON-RPC 2.0, carried over stdio (the host spawns the server as a local subprocess — no network overhead, ideal for desktop tools) or Streamable HTTP (remote servers that work with ordinary load balancers and CDNs). A session runs in four phases: initialize — client and server negotiate protocol version and capabilities; discovery — the client calls tools/list, resources/list, prompts/list and learns everything the server offers; operation — tools/call, resources/read as the model needs them; shutdown — clean close. Discovery is the whole trick: the agent meets a tool it has never seen and knows how to use it within one round trip.
REST, for contrast. No discovery, no session, no capability negotiation — you read the docs, hardcode the endpoints, pass a token, and handle each provider’s quirks yourself. That’s not a flaw; it’s the design. REST is a thin contract between two parties who agreed offline. MCP is a contract that introduces the parties to each other at runtime.
Where each one actually shows up
Claude Desktop + MCP servers. The canonical demo: point Claude Desktop at a filesystem server, a Postgres server, and a GitHub server. The agent reads your repo, runs queries against your database, and opens pull requests — three tools it never saw before, learned through discovery, zero custom integration code on your side.
IDE agents. Cursor and similar editors run one MCP client per connected tool. Add a tenth tool and you add a tenth client/server pair; the editor itself doesn’t change. That’s the N+M property in production: each app implements MCP once, each tool exposes MCP once, and every pairing just works.
Enterprise tool sprawl. A company with a dozen internal services — ticketing, CRM, data warehouse, deploy pipelines — exposes each as an MCP server once. Every agent host in the org can then use all twelve. The REST version of this is a wiki page of endpoints and twelve hand-rolled clients that rot at different speeds.
The uniform-over-REST pattern. Plenty of production MCP servers are thin wrappers over existing REST APIs: the server translates tools/call into GET/POST underneath and presents the standard face to the agent. MCP is a layer, not a replacement — when you control both ends or need thin, fast integration, plain REST is still the right call.
The integration math, by hand
Five agent apps need the same twelve tools. The REST way: 5 × 12 = 60 bespoke integrations — sixty wirings to write, test, and maintain, each rotting at its own speed. The MCP way: 5 + 12 = 17 — five host implementations, twelve servers, and every pairing works. Add a sixth app and REST adds twelve more integrations; MCP adds one.
Three patterns in Python
The bespoke REST call, an MCP client discovering tools at runtime, and a minimal MCP server exposing one tool — the three shapes behind almost every “so how does the agent actually use it” follow-up. (Client/server snippets are illustrative, following the official MCP Python SDK’s shape.)
import json, urllib.request
# 1) REST: bespoke. you read the docs, hardcode the endpoint, pass the token.
def rest_get_user(user_id, token):
req = urllib.request.Request(
f"https://api.example.com/users/{user_id}",
headers={"Authorization": f"Bearer {token}"},
)
return json.load(urllib.request.urlopen(req)) # schema? hope the docs were right
# 2) MCP client: no docs, no hardcoding. the server introduces itself.
async def mcp_use_tool(session, goal):
caps = await session.list_tools() # discovery: tools/list
for tool in caps.tools: # names + descriptions + JSON schemas
if tool.description_matches(goal):
return await session.call_tool(tool.name, arguments=goal.args)
raise RuntimeError("no tool fits this goal")
# 3) Minimal MCP server: expose one tool, every host can use it.
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("repo-search")
@mcp.tool()
def search_code(query: str) -> str:
'Search the codebase for a symbol. The docstring becomes the tool description.'
return run_ripgrep(query)
# write once, run anywhere: stdio for local, Streamable HTTP for remote
mcp.run()
Six questions that test the real understanding
What to say (≈60 sec): “A REST API is a direct call to one service — you read the docs, hardcode the endpoints, pass a token, and handle that provider’s quirks yourself. MCP is a standard protocol for agent tool-use: the agent’s host runs one client per tool, and each server announces its tools, data, and templates with machine-readable schemas. So REST is bespoke per service; MCP is write-once, use-everywhere — N plus M integrations instead of N times M. And MCP connections are stateful sessions, where REST is stateless by design.”
Likely follow-up: “Is MCP a replacement for REST?” — no, it’s a layer. Many production MCP servers are thin wrappers over REST APIs underneath; you pick REST when you control both ends or need thin, fast integration.
What to say: “Four phases. Initialize: the client and server negotiate protocol version and capabilities over JSON-RPC. Discovery: the client calls tools/list and gets back tool names, descriptions, and JSON schemas. Operation: when the model decides it needs a tool, the host calls tools/call with arguments; the server executes and returns the result. Shutdown: clean close. The key insight is that discovery happens at runtime — the agent can use a tool it has never seen before after one round trip.”
What to say: “When an AI agent needs lots of tools with uniform semantics — you’re standardizing the tool belt. If five agent apps need the same twelve tools, REST is sixty bespoke integrations and MCP is seventeen. I’d still ship plain REST when I control both ends, when the client is a human-written frontend, or when I need the thinnest, fastest integration with no ceremony. And the pragmatic middle: wrap the REST API in an MCP server so agents get the standard face.”
What to say: “Because the agent meets tools at runtime that no human wired up in advance. With REST, a human reads docs and writes the glue — the model can’t do that step itself. With MCP, the server hands the agent its own capability list with schemas, so the model can plan tool calls for tools it never saw in training. Discovery turns integration from a human task into a protocol step, and that’s what makes the tool belt scale.”
What to say: “Treat them like database drivers — they run code. A malicious or buggy filesystem server can read anything its process can, SSH keys included. The protocol helps: servers are isolated behind their own client, they never see the full conversation or each other, and the host enforces the security policy. But isolation isn’t a sandbox — so vet servers like dependencies, run them with least privilege, and always set timeouts so one hung server can’t hang the agent.”
What to say: “The host is the AI app — it owns the conversation, the model, and user consent. It spawns one client per server: a protocol adapter with a 1:1 connection. That indirection buys isolation and uniformity: each server is contained behind its own client and config, a misbehaving server can’t see the other tools, and adding a tenth tool means adding a tenth pair — the host code never changes. Without the client layer, every server integration would be bespoke host code, which is exactly the N-times-M problem MCP exists to kill.”
Key takeaways
- REST is a direct, bespoke call to one service — you wire each by hand. MCP is a standard protocol that lets agents discover and use any compliant tool with no custom glue: one plug, many tools.
- The architecture is host → one client per tool → servers. Servers expose tools (actions), resources (data), and prompts (templates); isolation between servers is deliberate.
- Discovery is the superpower: tools/list teaches the agent a new tool in one round trip, turning integration from a human task into a protocol step.
- Two sharp differences for the interview: standardization (N+M integrations instead of N×M) and sessions (MCP is stateful, REST is stateless by design).
- MCP is a layer, not a replacement — many production MCP servers wrap REST APIs underneath. Pick MCP when an agent needs many tools with uniform semantics; pick REST when you control both ends or need thin, fast integration.
Sources & further reading
Every claim in this guide traces to one of these — the wording is ours, the ideas are credited.
- Model Context Protocol — official specification (architecture: host, client, server; tools, resources, prompts; JSON-RPC 2.0; stdio and Streamable HTTP transports)
- The Agents Desk: “What is MCP?” (Nov 25, 2024 release; Linux Foundation Agentic AI Foundation stewardship from Dec 9, 2025; USB-C-for-AI framing; 10,000+ public servers)
- awesome-mcp-servers: MCP overview (three roles and primitives; OpenAI, Google DeepMind, and Microsoft adoption)
- MDN: HTTP reference (REST fundamentals — verbs, statelessness, request/response semantics)