MCP vs API: what is the difference?

You have an API for your product. Someone says "just expose it over MCP". Now you are wondering what that actually changes. Fair question, and the honest answer is smaller than the hype and bigger than "it is just another wrapper".

The short answer#

An API is the front door of one specific service. A developer reads its docs, then writes code that calls its endpoints.

MCP (Model Context Protocol) is a common language between AI apps and servers that offer tools and data. The AI app asks the server "what can you do?", gets a machine-readable list, and the model decides when to call each tool.

So the difference is who the interface is for. APIs are written for programmers who read docs. MCP is written for software that has to figure out, at runtime, what is available and how to use it.

Why a protocol at all?#

Say you have 4 AI apps (a chat app, a coding agent, an IDE, your own bot) and 5 services (GitHub, your database, Slack, a docs site, your ticket tracker). With plain APIs, every app needs custom glue for every service. That is 4 × 5 = 20 integrations, each with its own auth shape, error format and tool descriptions.

With MCP, each service ships one server and each app ships one client: 4 + 5 = 9 pieces. That is the whole pitch. It is the same trick as the Language Server Protocol did for editors and programming languages.

MCP vs API, side by side#

What MCP actually standardizes#

Three things a server can offer:

• Tools: actions the model can choose to call (search_issues, run_query). The model decides.
• Resources: data the app can read and attach as context (a file, a schema). The application decides.
• Prompts: reusable templates the user picks, like slash commands. The user decides.

And two standard ways to connect: stdio for a local server the app starts as a subprocess, and Streamable HTTP for remote servers. Messages are JSON-RPC 2.0 on both.

The same action, both ways#

Listing open bugs through a regular REST API:

curl -H "Authorization: Bearer $TOKEN" \
  "https://api.example.com/issues?state=open&label=bug"

You wrote that call, you parsed that JSON, you decided when it runs. Through MCP, the AI app sends a standard message after discovering the tool:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "search_issues",
    "arguments": { "state": "open", "label": "bug" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

The _meta block is how the latest spec revision identifies the protocol version and client capabilities on every request; older revisions did that once in a handshake. Nothing else here is specific to this service. The same envelope works for a calendar, a database or a deploy tool. The model never sees your auth header or your URL scheme; the server owns those.

When you do not need MCP#

If you build one app and you own the tools, define them directly with the model API's tool-use feature. You skip a process, a protocol and a layer of failure modes. Do not add MCP just because it is trendy.

When MCP is worth it#

• The same capability must work in several AI apps (desktop chat, terminal agent, IDE).
• You want to use servers other people built instead of writing integrations.
• You want the tool descriptions and permissions to live with the service, not copied into every app.

Three myths#

1. "MCP replaces APIs." It sits in front of them. Many servers are thin wrappers.
2. "MCP is a framework." It is a protocol, a spec for messages. SDKs exist, but the protocol is the point.
3. "MCP makes tools safe." It does not. A server that deletes files can still delete files. Treat servers like any dependency: least privilege, confirmation for risky actions, and read the code.

What to do next#

Build the smallest possible server and watch the messages go by. The MCP in Depth course starts with exactly that, in TypeScript, in about ten minutes.