Sonith ManakkatYou will hear two similar-sounding terms around AI tools: MCP and API. People often ask which one to use, as if they were competitors. They are not. This article draws the difference, shows how they fit together, and ends with one safe first step you can try. Facts come from the official MCP documentation and Claude Code documentation, checked on 2026-10-21 and listed at the end. Where something is my own view or analogy, it is labelled.
The USB-C idea
The official MCP introduction describes MCP as an open-source standard for connecting AI applications to external systems, and offers a comparison: think of MCP like a USB-C port for AI applications. Just as USB-C gives electronic devices one standard way to connect, MCP gives AI applications one standard way to reach files, databases, search engines and other tools.
Before a standard port
- A different cable for every gadget
- Each pairing is built separately
With a standard port
- One kind of socket on the device
- Any gadget that fits can connect
The waiter and the menu
- The AI app is the dinerIt wants something done
- The MCP client is the waiterOne waiter, one standard way of asking
- The server lists what is on offerTools, resources and prompts
- The kitchen does the workOften by calling its own API
Who is the caller, and how are tools found
With a normal API, a developer reads the documentation, writes code that calls specific addresses, and hard-codes the details. With MCP, an AI application connects to a server and asks it what it offers, and the model decides during the conversation whether to use something.
Ordinary API
- A developer reads the documentation
- Calls are written into the code ahead of time
MCP
- The client asks the server for its tools
- The model picks a tool as the conversation needs it
One request in each world
- The app sends an HTTP requestOften REST with JSON
- The gateway checks itSign-in, limits, routing
- A service does the workThen sends back JSON
- The developer's code uses itExactly as it was programmed
- You ask Claude somethingIn an AI application
- The client already listed the toolsFrom each connected server
- The model asks to use oneYou may be asked to approve
- The server runs it and repliesThe result goes back into the chat
- Claude to MCP server When it connects, the client sends a tools list request.
- MCP server to Claude (reply) The server describes the tools it offers.
- You to Claude You ask for something one of the tools can do.
- Claude (to itself) The model chooses a tool that fits the request.
- Claude to You You may be asked first. The specification says a human should be able to deny tool calls.
- You to Claude (reply) If you decline, the call does not happen.
- Claude to MCP server The client sends a tools call request.
- MCP server to Claude (reply) The server runs it, often through its own API, and replies.
- Claude to You (reply) The result goes back into the chat and Claude writes the reply.
Takeaway. The model proposes, a human can veto, and the server does the work.
Partners, not rivals
Why a shared standard helps, as simple arithmetic:
- 12Custom links: 3 AI apps times 4 tools
- 7With a standard: 3 apps plus 4 servers
The official introduction summarises the benefit as "build once and integrate everywhere". The numbers above only show the shape of the idea.
How it compares
| Aspect | API | MCP |
|---|---|---|
| Purpose | Let software call other software | Let AI applications use tools and data in a standard way |
| Typical caller | A developer's program | An AI application, on behalf of the model |
| Discovery | Read documentation, write code | Ask the server what it offers |
| Message format | Varies: REST with JSON is common | JSON-RPC 2.0 |
| Where it runs | Over the network, usually HTTP | Locally over stdio, or remotely over Streamable HTTP |
| State | Varies by design | The current MCP revision is described as stateless |
| Sign-in | API keys, tokens, OAuth | Optional; OAuth-based for HTTP servers, environment credentials for local ones |
| Best for | Anything that is not an AI client | Giving AI applications a reusable connection |
| Drawback | Each integration is custom work | Every server you add is more code and more trust |
Safety: the part not to skip
- PermissionsGive each server only the access it needs
- Approval promptsThe specification says a human should be able to deny tool calls
- Prompt injectionText a tool fetches can contain instructions meant to trick the model
- TrustA server is code or a service you choose to run or talk to
Which should I use?
- Is an AI application the one calling?If not, a normal API is the answer
- Does a trusted MCP server already exist?Use it before building your own
- Do you need a custom connection?Build a small server that wraps your API
- Start read-only and smallAdd write access later, with approval on
- 1Should everyone on the project get it through version control?Yes Project scope, stored in .mcp.json. Claude Code asks each person for approval before using it.No keep going
- 2Do you want it in all your own projects, private to you?Yes User scope.No keep going
- 3OtherwiseLocal scope, the default: only in this project, private to you. Best for trying a server out.
Takeaway. Start with local scope, and widen it only once you trust the server.
Try it: one safe first step
Expert viewHow the messages work
MCP uses JSON-RPC 2.0 for its messages, in two layers: a data layer that defines the messages and primitives, and a transport layer that carries them. The standard transports are stdio (a client-launched subprocess, usually serving one client) and Streamable HTTP (HTTP POST with optional streaming, usually serving many). Claude Code's documentation marks the older SSE transport as deprecated. A client lists tools with a tools list request and runs one with a tools call request. In the current revision (2026-07-28), the protocol is stateless: each request carries the protocol version and capabilities, and a discover request lets a client learn a server's capabilities before anything else. Earlier revisions used an initialize handshake, so older servers behave differently.
Expert viewSign-in and remote servers
Authorization is optional in MCP. For HTTP-based transports, the specification describes an OAuth 2.1 based flow, with the server acting as a resource server, and it says to use scopes that follow least privilege. For stdio servers, it says implementations should not follow that flow and should retrieve credentials from the environment instead. In Claude Code, you complete a remote server's sign-in with the /mcp command, and the documentation says tokens are stored securely and refreshed automatically.
Expert viewContext cost and scale
Every tool definition takes space in the model's context. Claude Code's documentation says tool search is enabled by default for MCP tools: only tool names and server instructions load at session start, and full definitions are fetched when Claude needs them, so extra servers have minimal effect on context. Skills follow a similar load-on-demand idea; see Skills explained and Context explained. Tool output size is also limited: Claude Code warns when an MCP tool result exceeds 10,000 tokens and caps it at 25,000 by default.
Expert viewTrust, supply chain and sharing
A local server is a program you download and run, so it carries ordinary software supply-chain risks: a malicious startup command, a malicious package, or an insecure local service. The official guidance recommends consent dialogs that show the exact command, sandboxing and minimal privileges, and for servers meant to run locally, the stdio transport so only the client can reach them. In Claude Code, servers can be saved at local, project or user scope; project scope writes a .mcp.json file that can be shared through version control, and Claude Code asks for approval before using project-scoped servers. For team use, see Reuse context and share it with your team.
An API is the doorway to one building. MCP is a standard way for an AI to knock on any door.
Frequently asked questions
Does MCP replace APIs?
No. MCP is a standard way for AI applications to connect, and many servers call ordinary APIs behind the scenes.
Do I need MCP to use Claude?
No. Claude works without it. MCP is for connecting Claude to your own tools and data.
Is every MCP server safe?
No. Treat each server like software you are choosing to trust, and review what it can do.
Is this the same as Skills?
No. Skills package instructions and know-how for Claude; MCP connects Claude to outside systems. They can be used together.