Start here: the basics

MCP vs APIs: what is the difference?

Most MCP servers sit on top of an API. The API stays the same, and the server describes it in a way an AI agent can use without a developer writing each request.

By
Dan Flanagan
Updated
October 14, 2026
Checked against
the MCP specification and docs (modelcontextprotocol.io), October 2026
Reading time
3 min

An API is a list of requests a service accepts. GitHub's API takes GET /repos/acme/web/issues and returns that repository's issues. A developer reads the docs, picks the request, and writes it into the program.

An AI model can't work that way. It decides what to do in the middle of a conversation, and nobody wrote the request for it ahead of time. An MCP server fills that gap by describing what the API can do as tools the model can look up and call.

Top: a developer's app sends the request it was programmed to send straight to the GitHub API. Bottom: an AI agent asks an MCP server which tools it has, gets back search_issues and create_issue with descriptions, calls search_issues, and the MCP server sends the same GET request to the same GitHub API.The same request reaches the same API either way. With MCP, the agent finds the tool and decides to use it.

What the server adds

The agent starts by asking the server what it has, with a request called tools/list. Back comes a list of tools, each with a name, a sentence on what it does, and the inputs it takes. For example: search_issues, "Search issues in a repository by text and status."

To use one, the agent sends tools/call with the tool's name and inputs. Every tool is called that way, whatever it does underneath.

The server then turns that call into the real API request and returns the result. GitHub never knows an AI was involved.

Side by side

An API compared with an MCP server
APIMCP server
Who uses itCode a developer wroteAn AI agent, through an AI app
How you find out what it can doRead the documentationAsk the server with tools/list
How actions are describedEndpoints and parameters in docsTool names and descriptions a model reads
How it is calledA different request for each actiontools/call with the tool name and inputs
How access worksAPI keys or OAuth, set up by the developerThe same keys or OAuth, held by the server or the app
ExampleGET /repos/acme/web/issuessearch_issues with "checkout" and "open"

Look at the access row. The server reaches the API with a key, so it can do whatever that key can do. If the key can merge pull requests, any agent that can call the server's merge tool can merge too. This is why teams decide tool by tool what each agent gets, which MCP permissions goes into.

MCP client vs MCP server

The client is the part of the AI app (Claude Code, Cursor, ChatGPT) that connects to a server and calls its tools when the model decides to. The server is the program offering the tools.

An app connects to as many servers as you add, with one client for each. A server doesn't care which app is calling, as long as it speaks MCP. What is an MCP server? follows one request from start to finish.

Turning an API into an MCP server

Since the server is mostly a description of the API, you can often generate one. Many APIs publish an OpenAPI spec, a file listing every request the API accepts, and a generator can turn each request into a tool.

Statio's mcp-gen does this, and How to turn an OpenAPI spec into an MCP server walks through it. To write one by hand, start with the Python or TypeScript tutorial. Check the catalog first, though. The API you want may already have a server.

Questions

No. Most MCP servers call a REST API underneath. The API keeps working for regular code exactly as before.

Most can, and an API with an OpenAPI spec is the easiest. A very large API works better as a few general tools, because a model handed hundreds of tools picks badly.

Often, yes. A good one also leaves out the requests an agent should never make.