# MCP vs API: what is the difference?

> An API is how your code talks to one service. MCP is a shared protocol that lets any AI app discover and call tools from many servers. Here is when to use each.

Source: https://devaiper.com/blog/mcp-vs-api
Published: 2026-10-08
Topics: MCP, API, Tool use, Agents

**Short answer:** An API is one service's interface, written for developers. MCP is a standard protocol that lets any AI app find and call tools on any server without custom glue. Most MCP servers wrap an API, so it is not either/or.

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.

> **Diagram:** Without MCP every AI app needs a custom integration for every service, 4 apps times 5 services is 20 integrations. With MCP each app has one MCP client and each service has one MCP server, so 4 plus 5 is 9 pieces.
> Chat app, Coding agent, IDE, Your own bot ↔ MCP ↔ GitHub, Database, Slack, Docs site, Ticket tracker
> N apps plus M services, instead of N times M custom integrations.

## MCP vs API, side by side

| | Regular API | MCP |
|---|---|---|
| **Who calls it** | Your code | An AI app (the host), on behalf of the model |
| **How you learn what exists** | Read the docs, write the client | The client asks `tools/list` at runtime |
| **Shape** | Different for every service (REST, GraphQL, gRPC) | One shape: JSON-RPC 2.0 with tools, resources and prompts |
| **Descriptions for the model** | You write them when you wire up tool use | The server ships them with each tool |
| **Reuse across AI apps** | Re-integrate in each one | Write the server once |
| **State** | Whatever the service chooses | Earlier revisions opened a session with an `initialize` handshake. The latest spec is stateless: each request carries its protocol version and client capabilities |

## 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:

```bash
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:

```json
{
  "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](https://devaiper.com/courses/mcp-in-depth) starts with exactly that, in TypeScript, in about ten minutes.

## FAQ

### Does MCP replace APIs?

No. An MCP server usually calls a regular API underneath. MCP standardizes how an AI app finds and calls that capability; the API still does the real work.

### Is MCP only for Claude?

No. MCP is an open protocol. Claude Desktop, Claude Code and many IDEs and agent frameworks act as MCP clients, and a server you write once works with all of them.

### Do I need MCP to give an LLM tools?

No. If you control the app, you can define tools directly in the model API's tool-use feature. MCP pays off when the same tools must work across several AI apps, or when you want to use servers other people built.

### What transport does MCP use?

Two standard ones: stdio for local servers started as a subprocess, and Streamable HTTP for remote servers. Messages are JSON-RPC 2.0 either way.