---
title: "MCP vs API: What's the Difference, and Why Claude Uses MCP (2026)"
description: "An MCP server usually just wraps an API, so why does AI need a whole new protocol? Here's the plain-English difference, why it matters for Claude, and when a plain API call is still the better choice."
date: "2026-10-17"
tags: [ai, mcp, model-context-protocol, api, claude, claude-code, ai-agents, explainer]
agent_task: "Look at the tools and services I connect my AI to and sort them: which should be an MCP server, which should stay a plain API call or CLI, and what access scopes each one actually needs."
sources:
  - title: "Model Context Protocol specification"
    url: "https://modelcontextprotocol.io/specification"
  - title: "Introducing the Model Context Protocol (Anthropic)"
    url: "https://www.anthropic.com/news/model-context-protocol"
  - title: "MCP connector (Claude API docs)"
    url: "https://platform.claude.com/docs/en/agents-and-tools/mcp-connector"
  - title: "Connect Claude Code to tools via MCP"
    url: "https://code.claude.com/docs/en/mcp"
---
Every time I talk about MCP, someone asks the same question: "Isn't that just an API?" And honestly? Fair. Most MCP servers are a thin layer sitting on top of an API that already existed. GitHub had an API. Slack had an API. Your database has had a query interface since before any of us were born.

So why did AI need a brand new protocol to talk to things that were already talking? The short answer: **APIs are written for developers. MCP is written for models.** That one difference explains almost everything, including why Claude leans on it so hard. Here's the longer answer.

## Table of Contents
1. [What an API Actually Is](#what-is-an-api)
2. [What MCP Actually Is](#what-is-mcp)
3. [The Real Difference](#real-difference)
4. [Why AI Needed Its Own Protocol](#why-ai-needs-mcp)
5. [How Claude Uses Both](#how-claude-uses-both)
6. [The Downsides of MCP](#downsides)
7. [When to Use Which](#when-to-use-which)
8. [TL;DR](#tldr)

---

## What an API Actually Is {#what-is-an-api}

An API (application programming interface) is a contract between two programs. One program says "send me a request shaped like this, and I'll send back data shaped like that."

Think of it like a restaurant menu. The kitchen decides what's on it, what each dish is called, and what you have to tell them (size, toppings, no onions). You don't walk into the kitchen. You order from the menu.

The important part: **a human reads the menu ahead of time.** A developer opens the docs, figures out which endpoint does what, handles auth, and writes code that calls `POST /repos/{owner}/{repo}/issues` with exactly the right fields. The program never "decides" anything. It does what the developer hard-coded.

Every API also has its own personality:

- Different auth (API keys, OAuth, signed requests)
- Different shapes (REST, GraphQL, gRPC, SOAP if you're unlucky)
- Different error formats, pagination styles, and rate limits
- Docs written for a person with coffee and patience

That works great when a developer is in the loop. It gets messy when the thing making the call is an AI that has never seen your docs.

---

## What MCP Actually Is {#what-is-mcp}

MCP (Model Context Protocol) is an open standard Anthropic released in November 2024 for connecting AI applications to outside tools and data. It's since been adopted across the industry and donated to the Linux Foundation's Agentic AI Foundation, so it's not a Claude-only thing anymore.

It has three pieces:

| Piece | What it is | Example |
|---|---|---|
| **Host** | The AI app you're using | Claude Desktop, Claude Code, claude.ai |
| **Client** | The connector inside the host that speaks MCP | One per server connection |
| **Server** | A small program that exposes capabilities | A GitHub server, a Postgres server, a Notion server |

A server can offer three kinds of things:

- **Tools**: actions the model can take ("create an issue," "run this query")
- **Resources**: data the model can read ("this file," "this table's schema")
- **Prompts**: reusable templates a user can pick ("summarize this PR")

Under the hood, it's JSON-RPC messages over one of two transports: **stdio** (the server runs as a local process on your machine) or **Streamable HTTP** (the server lives on the internet, usually with OAuth for login).

Back to the restaurant. If an API is the menu, MCP is a **waiter who walks up and tells you what's available tonight, in a language you understand, and then carries your order to the kitchen.** The kitchen didn't change. The way you find out what to order did.

If you want to build one, my [MCP tutorial](/blog/mcp-model-context-protocol-tutorial-ai-agents) walks through it. This post is about the *why*.

---

## The Real Difference {#real-difference}

Here's the side-by-side:

| | API | MCP |
|---|---|---|
| **Written for** | Developers | AI models (and the apps that host them) |
| **How you learn what it does** | Read the docs before you write code | Ask the server at runtime (`tools/list`) |
| **Who decides what to call** | The developer, in code | The model, in the moment |
| **Shape** | Different for every service | The same for every server |
| **Descriptions** | Docs for humans | Tool descriptions and schemas for models |
| **Connection** | Usually one request, one response | A session that can stay open and send updates |

The biggest one is the second row: **discovery**. When Claude connects to an MCP server, the first thing it does is ask "what can you do?" The server answers with a list of tools, each with a name, a plain-language description, and a JSON schema for its inputs. Claude reads that list the same way you'd skim a menu, then picks what fits the task.

Nobody had to write integration code for that specific service. Nobody had to read the docs. The server described itself.

The second big one is row three: **who decides**. With a normal API integration, your code calls the endpoint because you told it to. With MCP, the model decides which tool to call, with what arguments, based on what you asked. That's what makes it agentic. It's also what makes it risky (more on that soon).

And to be clear: **MCP doesn't replace APIs.** A GitHub MCP server still calls the GitHub API. MCP is a layer *on top* that makes the API usable by something that can't read docs ahead of time.

---

## Why AI Needed Its Own Protocol {#why-ai-needs-mcp}

Before MCP, connecting an AI to tools had a math problem. Call it **N × M**.

Say you have 5 AI apps (Claude, ChatGPT, Cursor, your company's internal bot, some VS Code extension) and 20 services you want them to use. Without a standard, somebody writes a custom integration for every pair. That's 100 integrations, each with its own auth handling, error handling, and bugs.

With MCP, each service writes **one** server and each AI app writes **one** client. That's 25 pieces of work instead of 100, and every new server instantly works everywhere. This is why people call MCP "USB-C for AI." You stop needing a different cable for every device.

There are a few other reasons a plain API wasn't enough:

**1. Models need descriptions, not docs.** A model choosing between 40 tools needs a short, clear sentence about each one and a strict schema for inputs. API docs are long, scattered, and written assuming a human will fill in the gaps.

**2. Models work at runtime, not compile time.** A developer integrates an API once and ships it. A model meets your tools fresh in every conversation. It needs a way to ask "what's here?" on the spot.

**3. The host needs control.** MCP keeps the AI app in the middle of every call. Claude Code can ask "allow this tool?" before it runs, log what happened, and let you turn servers on or off. With raw API calls from a model, you'd be building all of that yourself.

**4. Context is more than actions.** APIs are mostly about doing things. AI also needs to *read* things (files, schemas, docs) to give good answers. MCP's resources and prompts cover that side, not just the "do stuff" side.

---

## How Claude Uses Both {#how-claude-uses-both}

Here's where it gets fun, because Claude actually uses *both*, and the line between them is clearer once you see them next to each other.

### Tool use through the API (you're the integrator)

If you're building your own app on the Claude API, you can define tools yourself. You write the name, the description, and the input schema, and when Claude wants to use one, the API hands you a `tool_use` block. Your code runs it and sends the result back.

```typescript
const response = await client.messages.create({
  model: "claude-opus-5-5",
  max_tokens: 16000,
  tools: [
    {
      name: "get_order_status",
      description: "Look up the shipping status of a customer order by order ID.",
      input_schema: {
        type: "object",
        properties: { order_id: { type: "string" } },
        required: ["order_id"],
      },
    },
  ],
  messages: [{ role: "user", content: "Where's order 4417?" }],
});
```

Notice what's happening: this is basically hand-writing what an MCP server would tell Claude automatically. It's great when the tool only lives inside your app. It's tedious when you want the same tool in five apps.

### The MCP connector in the API (someone else did the work)

The Claude API can also connect straight to a remote MCP server for you. You point it at the server's URL, and Claude discovers and calls the tools itself, no tool-handling loop on your side. It's a beta feature, and you name the server in two places: once in `mcp_servers` and once as an `mcp_toolset` in `tools`.

### MCP in Claude Code and claude.ai (the everyday version)

This is where most people meet MCP. In Claude Code, adding a server is one line:

```bash
claude mcp add --transport http my-tracker https://mcp.example.com/mcp
```

From then on, Claude can see that server's tools in every session and ask your permission to use them. On claude.ai and Claude Desktop, the same idea shows up as **connectors**: you click to connect Google Drive or Gmail, sign in, and Claude can use them.

### Where skills fit

People mix these up, so quickly: **MCP gives Claude abilities. [Skills](/blog/claude-skills-setup-guide-why-you-need-them) give Claude know-how.** An MCP server lets Claude create a Jira ticket. A skill tells Claude how *your team* writes Jira tickets. They work well together.

---

## The Downsides of MCP {#downsides}

I like MCP a lot. It's still not magic, and I'd be lying if I pretended otherwise.

**1. Tool lists eat your context.** Every connected server sends its tool names, descriptions, and schemas to the model. Connect ten servers with 20 tools each and you've spent a real chunk of context (and tokens, and money) before you've asked anything. Newer setups help with this by loading tools on demand (Claude Code defers tool definitions and searches for them when needed, and the API has a tool search tool with `defer_loading`), but it's still worth trimming servers you don't use.

**2. Security gets harder, not easier.** The model decides what to call, and it reads whatever comes back. That opens doors for:
- **Prompt injection**: a GitHub issue or email that says "ignore your instructions and..." lands in the model's context through a tool result
- **Tool poisoning**: a sketchy server with a tool description that quietly tells the model to do something else
- **Over-broad access**: a server with a token that can delete repos when you only needed it to read them

Only install servers you trust, use the narrowest scopes you can, and keep approvals on for anything that writes.

**3. It's another moving part.** A local server is a process that can crash. A remote one is a service that can go down or change. A plain API call has fewer things to break.

**4. Sometimes the CLI is just better.** If Claude Code can already run `gh`, `psql`, or `curl`, it doesn't always need an MCP server for the same thing. Claude is very good at command-line tools it already knows. An MCP server earns its place when there's no good CLI, when you need OAuth handled for you, or when you want it to work outside the terminal too.

**5. Quality varies wildly.** Anyone can publish a server. Some are excellent. Some are a weekend project with vague tool descriptions that confuse the model and leak your tokens to a random host.

---

## When to Use Which {#when-to-use-which}

Here's how I decide.

| Situation | Use |
|---|---|
| Your own app calls a service in a fixed, predictable way | **Plain API call.** No model decision needed, so skip the extra layer. |
| You're building a Claude app with a tool that only exists inside it | **API tool use.** Define the tool yourself. |
| You want the same tool in Claude Code, Claude Desktop, Cursor and more | **MCP server.** Write it once, use it everywhere. |
| A good CLI already exists and you're working in a terminal | **Let Claude use the CLI.** It's often faster and cheaper on context. |
| You need the model to *read* live data (schemas, docs, tickets) to answer well | **MCP**, especially resources. |
| The service needs OAuth sign-in per user | **Remote MCP server** with OAuth. Don't hand-roll that. |
| The action is destructive or expensive | **Either**, but keep a human approval step in front of it. |

My rule of thumb: **if code is deciding, use an API. If a model is deciding, use MCP.** And if you're not sure a model needs to decide at all, it probably doesn't, and a plain API call (or a script) will be cheaper, faster, and easier to debug.

---

## TL;DR {#tldr}

| | API | MCP |
|---|---|---|
| What it is | A contract between programs | A standard way for AI apps to discover and use tools |
| Written for | Developers | Models |
| Discovery | Read the docs ahead of time | Ask the server at runtime |
| Who decides what to call | Your code | The model |
| Relationship | The foundation | Usually a layer on top of an API |

- **The one-line version:** APIs are menus for developers; MCP is a waiter who reads the menu to the AI.
- **Why it exists:** it turns N × M custom integrations into N + M, and gives the host app a place to ask permission and log calls.
- **How Claude uses it:** your own tools via API tool use, remote servers via the API's MCP connector, and `claude mcp add` or connectors in Claude Code and claude.ai.
- **Biggest catch:** tool lists cost context, and the model reading tool results opens the door to prompt injection. Trust your servers, scope your tokens, keep approvals on.
- **Rule of thumb:** code deciding, use an API. Model deciding, use MCP.

---

**More posts:**
- [Claude Code Review: What It Does, What It Costs, and Whether It's Worth $15-25 a PR](/blog/claude-code-review-cost-pros-cons)
- [Claude Code Mods, Explained: I Built One That Watches My Own Agent](/blog/claude-code-mods-2026)
- [The Habits I Use Coding With Claude (A Security-First, Token-Conscious Workflow)](/blog/senior-dev-habits-coding-with-claude)

---

*// hereshecodes.com*