An API is a contract that code calls: fixed endpoints, and a developer decides which one to call and when. MCP (Model Context Protocol) is a contract that an AI model calls: the server describes its tools in plain language, and the model decides at run time which one to use. The two do not compete. Most MCP servers sit in front of an ordinary API and call it for the model. Use the API when you know the steps in advance and want the same result every time. Use MCP when an AI agent has to choose the steps itself.

Last updated: 2026-09-28. Checked against MCP specification version 2026-07-28.

TL;DR

Question	Answer	Why
Does MCP replace APIs?	No	Most MCP servers are a thin layer that turns API endpoints into tools a model can find and call.
When should I call the API directly?	When your code decides the steps	A fixed call gives the same result every time, with no model cost and no randomness.
When should I use MCP?	When the model decides the steps	The model can list tools, pick one, read the result and pick again, across many apps.
What does MCP cost that an API does not?	Context tokens	Every tool description goes into the model's context. An unfiltered GitHub catalog measured about 300,000 tokens in our logs.
Is MCP stateful?	No, since 2026-07-28	The specification removed the `initialize` handshake and protocol sessions.
Who handles auth?	Your code for an API; the server for hosted MCP	Somebody still runs the provider's OAuth flow and refreshes its tokens.

How do MCP and an API compare side by side?

	API (REST, GraphQL)	MCP
Who calls it	Code that a developer wrote	An AI model, through an MCP client in the host app
Who picks the next call	The developer, at build time	The model, at run time
Discovery	A developer reads the docs	The client lists tools (`tools/list`) with names, descriptions and input schemas
Message format	Varies: JSON over HTTP, GraphQL, XML	JSON-RPC 2.0
Transport	HTTP	stdio (local subprocess) or Streamable HTTP (remote)
Auth	Whatever the provider requires	Optional in the spec. Remote servers: OAuth 2.1. Local servers: credentials from the environment
State	Stateless requests, by convention	Stateless since 2026-07-28. State lives in handles passed as tool arguments
Token cost	None. It is not in a model's context	Every tool name, description and schema the model sees costs tokens
Predictability	Same input, same call, every time	The model can pick a different path on each run
Best for	Scripts, backends, scheduled jobs, one fixed integration	Agents and assistants that act on many apps from natural language

Sources: MCP specification 2026-07-28, transports, authorization, all checked 2026-09-28.

What is an API?

An API (application programming interface) is a published contract between two programs. The provider lists endpoints, the parameters each one takes and the response it returns. A developer reads that documentation and writes code for each endpoint: GET /customers/123, POST /charges. The program then runs the same steps every time.

REST and GraphQL are the most common styles on the web today. Every major SaaS product, such as Gmail, Stripe, Notion or GitHub, exposes one.

What is MCP?

MCP is an open protocol for connecting AI applications to tools and data. Anthropic released it on 25 November 2024, and many clients now support it, including Claude Desktop, Claude Code, ChatGPT and Cursor (client list, checked 2026-09-28).

There are three roles:

Host: the AI application the user talks to, for example Claude Desktop.
Client: the connector inside the host that talks to one server.
Server: the program that offers capabilities.

A server can offer three kinds of feature, as the specification defines them: tools (functions the model can run), resources (data the user or model can read) and prompts (templated messages and workflows). For more detail on the server side, see What is an MCP server?.

How does an MCP server use an API?

In most cases the MCP server is a translator in front of an existing API:

User:   "Did Acme pay last month's invoice?"
Model:  picks the tool  find_invoices(customer="Acme", month="2026-08")
Client: sends it to the MCP server as a JSON-RPC tools/call
Server: calls the provider API  GET /v1/invoices?customer=cus_123&created[gte]=...
API:    returns JSON
Server: returns a short result to the model
Model:  "Yes, invoice INV-0042 was paid on 3 September."

The API still does the real work. MCP adds a description layer on top that a model can read, and one standard way for every client to call it. That is why "MCP vs API" is not an either-or choice for most teams: the API is the engine, and MCP is one of the ways to steer it.

Who decides the next step: your code or the model?

This is the question that settles most decisions.

Two lanes over the same provider API: on the left your code sends a fixed request and gets JSON back, on the right the model picks a tool, the MCP server sends the same request and the result loops back to the model

Use the API directly when your code decides. Examples: a nightly job that copies new Stripe charges into a spreadsheet, a webhook that opens a ticket when a form is submitted, a backend that fetches a user's calendar to show it in your app. The steps are known, so a model in the loop adds cost and randomness and gives you nothing in return.

Use MCP when the model decides. Examples: "find the three customers who complained most this week and draft a reply to each", "check why this campaign's spend jumped and pause the worst ad set". Nobody can write these steps down in advance. The model has to look, choose a tool, read the result and choose again. MCP gives it a standard way to do that across many apps.

A useful middle ground: an agent can also call an API through plain function calling or a CLI, with no MCP server at all. This works well when you control the agent and only need a handful of endpoints. MCP's advantage is reuse. One server works in every MCP client, and one client works with every MCP server. The tool calling guide covers how function calling and MCP relate.

What does MCP cost that an API does not?

Context tokens. A model can only choose a tool it can see, so every tool description has to go into its context window. Comparison pages rarely mention this, and it is the main cost of MCP in practice.

We measured this on ClawLink's own agent surface on 9 August 2026. The always-loaded tool list was about 5.7 KB (about 1,400 tokens). But a full, schema-hydrated catalog for GitHub alone (846 tools) came to about 1.14 MB, roughly 300,000 tokens. That does not fit in the context window of most models, and even a fraction of it slows the model down and makes it pick worse.

Two columns compare what enters the model's context: a capped list of tool names with one-line descriptions costs about 1,400 tokens, while GitHub's full catalog of 846 tools with every schema loaded costs about 300,000 tokens and overflows an example 200,000-token context window

The usual fixes:

Expose fewer tools. Keep an allowlist of the actions the agent actually needs.
Load schemas lazily. List tool names and one-line descriptions first. Fetch the full input schema only for the tool the model picks.
Use a search tool. Give the model a tool that finds tools by keyword, instead of a list of hundreds.

A plain API has none of this cost, because the model never sees it. Your code does.

Wrong arguments. A model can pass a placeholder such as YOUR_CUSTOMER_ID where a real id belongs, or leave out a field that changes what the call does. In ClawLink's logs this was the top class of failure that users could fix: 11,687 calls in the 90 days to 16 September 2026 (source). With a direct API call, your code catches this at build time.

How does authentication differ?

With a plain API, your code holds the credential (an API key or an OAuth token) and sends it on every request. You write the OAuth flow, store the tokens and refresh them.

MCP splits this by transport. The authorization specification (checked 2026-09-28) says:

Authorization is optional.
Servers on an HTTP transport should use its OAuth 2.1 based flow, where the MCP server acts as a resource server and the client gets a token for it.
Servers on stdio (local processes) should not use that flow, and read credentials from the environment instead.

Two layers of auth are easy to mix up. One is the client's token for the MCP server. The other is the server's token for the provider's API (Gmail, Stripe, and so on). Somebody still has to run the provider's OAuth flow, store those tokens and refresh them. A local server usually leaves that to you. A hosted MCP server does it for you. ClawLink (our product), Composio and Zapier MCP are examples of hosted servers. MCP server authentication and hosted vs self-hosted MCP servers go deeper on this trade.

Is MCP stateful or stateless?

Since the 2026-07-28 specification, MCP is stateless. The changelog (checked 2026-09-28) lists these changes:

The initialize handshake was removed. Each request now carries its own protocol version and client capabilities.
Protocol-level sessions and the Mcp-Session-Id header were removed from Streamable HTTP.
A server that needs state between calls hands out its own ids and receives them back as ordinary tool arguments.

Many comparison articles still describe MCP as "stateful sessions" and remote MCP as "HTTP plus Server-Sent Events". That was true of earlier versions. Clients and servers that have not upgraded may still speak the 2025 protocol, so check which version your client supports.

What does this look like in practice?

A worked example. A user connects Gmail to Claude Code through a hosted MCP server (here, ClawLink) and asks: "Summarize the unread emails from my team today."

Claude Code has one MCP server connected. Its short tool list includes a search tool, a describe tool and an execute tool, not hundreds of Gmail actions.
The model searches for "gmail list messages", gets back a few candidate actions, and fetches the input schema for only one of them.
It calls execute with is:unread newer_than:1d. The server takes the user's stored Google token, refreshes it if it has expired, and calls the Gmail API.
The server returns the messages. The model reads them and writes the summary.

Under the hood, step 3 is an ordinary Gmail API request. MCP decided how the model found and called it. It did not replace the API.

If you built the same feature into your own product, with a fixed "daily digest" button, you would skip MCP and call the Gmail API directly from your backend.

Which should you choose?

Your situation	Choose
One fixed integration, no AI in the loop	API
A scheduled job or webhook with known steps	API
Your own agent, 3 to 5 endpoints you control	API through function calling, or a CLI
An agent that must act on many apps from natural language	MCP
You want one integration to work in Claude, ChatGPT, Cursor and others	MCP
Users bring their own accounts and you do not want to build OAuth for each provider	A hosted MCP server
Strict compliance or audit needs every call to be predictable	API, or MCP with a small allowlist and human approval on writes

Frequently asked questions

Will MCP replace APIs?

No. Most MCP servers call an API underneath. MCP adds a layer that a model can read. It does not remove the need for the API.

Can an API be an MCP server?

An API can be wrapped by an MCP server, and many providers now ship one next to their API. For example, GitHub and Stripe publish official MCP servers. You can also write your own with one of the official SDKs.

Can an AI agent call an API without MCP?

Yes. Function calling (also called tool use) lets a model call any function you define, including one that sends an HTTP request. MCP standardizes this so that one server works across many clients.

Is ChatGPT an API?

ChatGPT is an app. The OpenAI API is the API. ChatGPT can act as an MCP client, so it can call tools on MCP servers (client list).

Is MCP slower than calling an API directly?

Each MCP call adds one hop (client to server) before the API call, and the model must spend tokens reading tool descriptions. For a fixed job, a direct API call is faster and cheaper. MCP pays off when the model saves you from writing and maintaining the logic yourself.

Is MCP secure?

It is as secure as the server and its scopes. An MCP server gives an agent real access to real accounts, so treat its tokens like privileged credentials: grant the smallest scopes, allowlist the tools, and require approval for writes. Is it safe to connect Gmail to an AI agent? walks through the risks.

Do I need to run my own MCP server?

Only if nobody offers one for your app, or you need full control. Local servers run on your machine over stdio. Hosted servers run elsewhere and handle OAuth for you. See hosted vs self-hosted MCP servers.

What should you read next?

What is an MCP server?: the host, client and server roles in more detail.
Tool calling for AI agents: how the model picks and calls tools, and why calls fail.
MCP server authentication: OAuth for remote servers, step by step.
Hosted vs self-hosted MCP servers: setup time, token refresh and failure modes compared.
Google Search Console MCP and Google Ads MCP: MCP in practice, on real marketing data.

MCP vs API: what is the difference and when should you use each?