MCP vs API: What's the Difference, and Why Claude Uses MCP (2026)

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.

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:

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 walks through it. This post is about the why.

Here's the side-by-side:

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.

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.

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.

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:

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 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.

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.

Here's how I decide.

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.