MCP vs API: what's the difference and when to use each

An API is how one program asks another for data or an action. MCP, the Model Context Protocol, is a standard way for AI apps such as Claude, ChatGPT, Cursor and Codex to find tools and call them. The two aren't rivals. Most MCP servers call an API underneath: the MCP server describes what an agent can do, and the API does the work.

So the useful question is when to call an API directly and when to put an MCP server in front of it. We ran the same GitHub request both ways on November 3, 2026, measured what each costs an agent, and used Corsair's own MCP server as a second data point. The numbers below come from those runs.

The short answer

• Use an API directly when you write the code: a product feature, a script or a batch job where you know which call to make and want every field and option.
• Use MCP when an AI agent decides what to do at runtime, and you want the same tools to work in Claude, ChatGPT, Cursor, Codex and any other MCP client.
• Often you use both. Your backend calls APIs, and your agents reach the same services through an MCP server.

The same request, both ways

We asked GitHub for the two newest open issues in the modelcontextprotocol/modelcontextprotocol repository, once through the REST API and once through GitHub's own MCP server.

Through the REST API

curl -H "Accept: application/vnd.github+json" \
  "https://api.github.com/repos/modelcontextprotocol/modelcontextprotocol/issues?state=open&per_page=2"

The reply had two items. The first, #3498, was a pull request, not an issue. GitHub's REST API treats every pull request as an issue, and its docs tell you to check each item for a pull_request field and filter those out yourself. The second item, issue #3492, came back with 34 fields: URLs for comments, events, labels and the timeline, reaction counts, lock status, node IDs and more. That one issue was 5,395 characters of JSON.

None of that is wrong. An API is a contract for developers, and it gives you everything so that any program can use it. You read the docs, learn the quirks and write code that handles them.

Through the GitHub MCP server

An MCP client talks to a server in JSON-RPC 2.0. Asking for the same issues looks like this:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "list_issues",
    "arguments": {
      "owner": "modelcontextprotocol",
      "repo": "modelcontextprotocol",
      "state": "OPEN",
      "perPage": 2
    }
  }
}

The reply listed issues #3492 and #3491, with no pull request in between. Each issue had nine fields: number, title, body, state, user, assignees, comments, and the created and updated times. Issue #3492 was 3,054 characters, and its body was the same 2,727 characters the REST API returned. The MCP tool did the filtering and trimming the REST API leaves to you, and it did it in a shape written for a model to read.

So the API stays the source of truth, and the MCP server decides what an agent sees and how it asks.

What MCP adds on top of an API

Tools that describe themselves

A client can ask any MCP server for its tools with tools/list. Each tool comes back with a name, a plain-language description and a JSON Schema for its inputs, so the model reads what it can do at runtime instead of a developer reading docs ahead of time. An API can publish an OpenAPI file, but nothing makes a client fetch it, and many APIs don't have one.

One protocol for every service

Every MCP server speaks the same JSON-RPC messages: initialize, tools/list, tools/call. Every API has its own URLs, pagination, error format and auth. An agent that can use one MCP server can use all of them without new code, which is why one connector works across Claude, ChatGPT, Cursor and Codex.

Two ways to connect

The current spec, dated July 28, 2026, defines two transports. A local server runs on your machine and talks over standard input and output, which the spec calls stdio. A remote server takes requests at a URL over Streamable HTTP. GitHub's server returned an Mcp-Session-Id header on initialize, and our later calls sent it back, so one conversation is one session. Most REST APIs treat each request on its own.

Sign-in built into the protocol

MCP's authorization spec is optional, and where a remote server uses it, it's built on OAuth 2.1. A client can register itself with the server and send you through the sign-in in your browser, so you add a server by URL and sign in once. Local stdio servers skip this and read credentials from the environment, the way a script reads an API key. With a plain API, every app makes you create a key or set up OAuth yourself.

What the tool list costs an agent

Most MCP vs API comparisons skip this part. Every tool an MCP server exposes sits in the agent's context before it does anything. We measured GitHub's MCP server:

• 49 tools for GitHub alone.
• The names, descriptions and input schemas the model reads came to 52,513 characters, roughly 13,000 tokens at about four characters per token.
• The full tools/list reply was 136,248 characters. 78,156 of those were icons, which clients show to people rather than send to the model.

One tool per API endpoint is the obvious way to build an MCP server, and it adds up fast. Connect five servers built that way and you can spend tens of thousands of tokens on tool descriptions before the agent reads your question.

Corsair's MCP server is built the other way. It has 11 tools, and their names, descriptions and schemas come to 9,292 characters, roughly 2,300 tokens. Those 11 tools reach 409 apps and 14,356 operations, because the tools are for finding and running operations rather than one tool per endpoint: list_operations finds what an app can do, get_schema shows the arguments, and run_script runs the call. The agent only loads the detail for the operation it needs.

Dev Jain at Corsair tested this in April. He wrapped the same integration layer as an MCP server with four tools and as a CLI with four commands, connected six apps, and ran three tasks three times each through both, 18 runs in all. The numbers converged with no consistent winner. The protocol wasn't what made the difference. The tool design was.

When to use an API, and when to use MCP

Call the API directly when:

• you're writing the code and know which call you need, such as a "Sync from Airtable" button or a nightly export;
• you need every field, option and edge case the API offers;
• the work runs at volume, where a model reading tool descriptions adds cost for no benefit.

Use an MCP server when:

• an agent picks the action at runtime from what the user asks;
• you want the same tools in Claude, ChatGPT, Cursor, Codex and other clients without writing an integration for each;
• you'd rather people sign in once through the server than hand you API keys;
• you need the server to check each action, for example to ask a person before anything is deleted.

Use both when your product and your agents touch the same services. Your backend keeps calling the APIs, or an SDK over them, and your agents reach those services through an MCP server that holds the same credentials and rules.

Where the credentials live

With an API, the key or token sits in your code, your environment or your secret manager, and your program attaches it to each request. If a model writes and runs that code, the model can see the key.

With a well-built MCP server, the server holds the credentials and attaches them when it calls the API, so the model only sees tool names, arguments and results. That moves the risk rather than removing it. The server now holds the keys, so how it stores and isolates them matters. And an agent can still be talked into a bad action by a prompt hidden in an email or a web page, so permissions should be checked on the server, in code, not left to the model. Corsair's security page explains how it encrypts credentials and checks each action against the mode a person picked.

How to turn an API into an MCP server

There are three common ways:

1. One tool per endpoint. Wrap each API call as a tool. It's quick to build, but the tool list grows with the API, as GitHub's 49 tools show.
2. A few tools for finding and running operations. Expose search, describe and execute tools, and let the agent look up the endpoint it needs. This keeps the tool list small however large the API gets.
3. Use an integration layer that already does it. Corsair connects 409 apps behind one MCP address, https://mcp.corsair.dev/mcp, with sign-in, approvals and the small tool list above. Our guides show how to add it in Claude and in Codex.

FAQs

Is MCP going to replace APIs?

No. MCP servers call APIs underneath, so MCP depends on them. MCP replaces the custom glue code that connected each AI app to each API, not the APIs themselves.

Is MCP like an API gateway?

Partly. Both sit in front of services and handle access, but an API gateway routes and secures requests for programs, while an MCP server describes tools so an AI model can choose and call them.

How do you convert an API to an MCP server?

Wrap the API's operations as MCP tools, either one tool per endpoint or a few tools that search for and run operations, or put the API behind an integration layer that exposes it over MCP for you.

Does MCP use API keys?

It can. Local stdio servers usually read an API key from the environment, and remote servers usually sign you in with OAuth. Either way the server holds the credential, not the model.

Is MCP a REST API?

No. MCP uses JSON-RPC 2.0 messages over standard input and output or over Streamable HTTP, not REST endpoints, though many MCP servers call REST APIs behind the scenes.

Is MCP better than calling an API directly?

For an AI agent that chooses actions at runtime, usually yes. For code you write yourself with a fixed flow, calling the API directly is simpler and cheaper.

Should an agent use MCP, an API or a CLI?

It depends on the tool design more than the interface. In our 18-run test, an MCP server and a CLI built on the same integration layer performed about the same.