← All resources

— Guide

MCP vs API: what an MCP server actually adds

Every brief now asks whether it needs an MCP server. The honest answer usually starts with the API you already have.

By Level UI13 min read

Somewhere in the last year, "do we need an MCP server?" joined "do we need an app?" on the list of questions that arrive in a brief before anyone has said what the thing is for. It is usually asked as though MCP were a newer, better kind of API, something to migrate to. It is not. An MCP server is a translation layer between an AI application and a system that almost always has an API already, and in most real projects it calls that API on every single request. Here is what each one is for, where the line between them sits, what building a server really takes, and the part the demos leave out.

MCP vs API, side by side

What differsAPI (REST, GraphQL)MCP server
Written forA programmer, who reads the documentation and writes code against itAn AI model, which reads the list of tools at runtime and decides what to call
How capabilities are foundDocumentation, an OpenAPI file, a support ticketAsked for live: the client calls tools/list and gets names, descriptions and JSON Schemas back
Who decides what gets calledThe developer, in advance, in codeThe model, in the moment, ideally with a person approving anything consequential
On the wireHTTP methods and URLs, usually JSONJSON-RPC 2.0 messages, over stdio locally or Streamable HTTP remotely
ConnectionUsually stateless, one request at a timeStateless too, since the July 2026 revision: every request carries its own version and capabilities
What it exposesEndpointsTools (actions), resources (data to read) and prompts (reusable templates)
AuthenticationWhatever the provider chose: keys, OAuth, sessionsFor remote servers the spec recommends OAuth 2.1, and forbids passing the client’s token on to the API behind
Typical failureA bug: the code called the wrong endpointA judgement: the model was talked into calling the right tool for the wrong person
Replaces the other?NoNo. It usually calls the API on every request

The MCP column follows the specification current in September 2026, revision 2026-07-28. Resources and prompts are optional, and plenty of servers expose tools only.

What MCP actually is

The Model Context Protocol is an open standard, published by Anthropic in November 2024, for connecting AI applications to outside systems. Its own documentation reaches for the analogy of "a USB-C port for AI applications": one connector shape, so any AI application that supports it can plug into any system that offers it, instead of every pairing needing its own cable.

There are three roles. The host is the application a person actually uses: Claude, ChatGPT, an editor like VS Code or Cursor. Inside it, a client holds one connection to one server. The server is the piece you would build, a program that tells the client what it can do and then does it. The two speak JSON-RPC 2.0, over standard input and output when the server runs on the same machine, or over Streamable HTTP when it runs somewhere else.

A server can offer three kinds of thing. Tools are actions the model can invoke: search orders, create an invoice, book a slot. Resources are data the application can read into the conversation, like a file or a record. Prompts are reusable templates a person can pick from a menu. In the other direction, a server can stop halfway through a task and ask for more, most usefully through elicitation, a question put to the user.

The protocol is still moving quickly, and a lot of what was written about it in 2025 now describes an older version. The current revision, dated 28 July 2026, removed the opening handshake and protocol-level sessions altogether, so every request now carries its own version and capabilities, much like an ordinary API call. It moved long-running tasks into an optional extension, and deprecated sampling and roots, the features that let a server borrow the host’s model or ask which folders it may touch.

The difference in one sentence

An API tells a programmer what a system can do; an MCP server tells a model, at runtime, in words it can reason about. Everything in the table above follows from that. An API assumes somebody read the documentation, chose the endpoints, handled the errors and shipped code that calls them the same way every time. An MCP server assumes nobody did: the model discovers the tools when it connects, reads their descriptions, and decides for itself which one fits what the user has just asked.

That is why tool descriptions matter far more than endpoint documentation ever did. A vaguely named endpoint costs a developer ten minutes. A vaguely described tool costs you every conversation in which the model picks the wrong one, or the right one with the wrong arguments, and nobody notices, because the answer still sounds confident.

MCP servers wrap APIs. They do not replace them

Look inside almost any MCP server and there is an API call at the bottom of it. GitHub’s official server calls GitHub’s API. When you ask an assistant to open an issue, the chain runs like this: the model picks the tool, the client sends a JSON-RPC request, the server turns it into an ordinary HTTPS request to the API that has existed for years, and the answer travels back the same way.

We work this way ourselves. We use MCP servers in our own work every day, Blender and Hugging Face among them, and each one is a thin layer over an interface that was already there: Blender’s Python API, the Hugging Face Hub API. The layer is what lets a model use them without anyone writing new glue for every task.

So the real question is never "API or MCP". If your system has no API, you do not need an MCP server yet. You need an API, and the server comes after it. If it already has a good one, the server is a comparatively small layer on top. Choosing the API underneath is its own decision, and REST vs GraphQL covers it.

Why a standard, and not just function calling

Models could call functions before MCP existed. Every major provider has a tool-calling feature where you send a list of functions along with a request and the model answers with the one it wants run. The difference is who owns the wiring. With plain function calling, each application defines its tools in its own code, for one model provider. With MCP, the tool definitions live in the server, and any compatible host can connect to them.

That turns what used to be a multiplication, every AI application building a separate integration for every system, into an addition: each application implements a client once, each system implements a server once. It is the reason the protocol spread as fast as it did. OpenAI adopted it in March 2025, Google said in April that Gemini would support it, and Microsoft and GitHub joined its steering committee in May. In December 2025 the protocol moved into the Agentic AI Foundation, a new home under the Linux Foundation co-founded by Anthropic, OpenAI and Block, with Google, Microsoft, AWS and Cloudflare among its members. That step matters more than it sounds: it is the difference between one vendor’s feature and the industry’s plumbing.

When an MCP server is worth building

Three situations, and they have one thing in common: whatever calls your system is an AI model somebody else chose. First, you sell a product with an API and your customers already work inside AI assistants. A server lets them use your product from there, and more and more of them expect to. Second, your staff want to ask internal systems questions in plain language (orders, stock, tickets) from the assistant they already use, without you building a chat interface of your own. Third, you want one integration to serve every AI application rather than one per vendor.

And three where it is the wrong tool. A fixed process with known steps, such as "when an order arrives, create the invoice and email it", wants deterministic automation calling the API directly; a model deciding each step adds cost and a new way to fail, and gains nothing. We compared the platforms for that half in Zapier vs Make vs n8n. A single integration between two of your own systems wants a plain API call. And anything that moves money or deletes data wants a person in the loop, which MCP makes possible but does not enforce.

What building one really takes

The protocol side is the easy part. There are official SDKs for most mainstream languages, including TypeScript, Python, C#, Go, Java and Kotlin, and a server that wraps three endpoints of an existing API runs to a few hundred lines. If a demo is all you need, it is a day’s work.

The production work sits elsewhere, and so does the estimate. Designing the tools for a model rather than a programmer comes first: fewer, higher-level tools, with descriptions written for the reader who will really use them. Anthropic’s own guidance calls tools that "merely wrap existing software functionality or API endpoints" a common error, and its example is a single search_contacts tool in place of a list_contacts that makes the model page through everyone. Then authorization, which for a remote server means OAuth 2.1, protected resource metadata, a check that every token was issued for your server, and never forwarding the client’s token to the API behind it, which the specification explicitly forbids. Logging every tool call with who asked and what happened. Scopes and rate limits, because a model will cheerfully call a tool four hundred times if the task seems to call for it. That is the part of an API & Integrations project that takes the time.

There is also a cost that lands on the model’s side rather than yours. Every tool definition is loaded into the model’s context. Anthropic’s engineers worked through an example in which tool definitions and intermediate results passing through the model came to 150,000 tokens, and cut it to about 2,000 by having the model write code against the servers instead. Every tool you expose is a cost on every conversation, so a few good tools beat a mirror of your whole API.

Security: the part the demos skip

An MCP server gives a model hands, and a model takes instructions from anything it reads. That combination has already produced a year of real incidents. In April 2025 Invariant Labs showed tool poisoning: instructions hidden in a tool’s description, invisible to the user and obeyed by the model. In May 2025 the same team showed a crafted issue in a public GitHub repository making an agent that used the official GitHub server leak data from private ones, and were clear that the fault was not in the server’s code but in the architecture. In June 2025 Asana took its MCP server offline for almost two weeks after a logic flaw exposed some data to other organisations; the company put the number of affected customers at roughly 1,000. In July 2025 a flaw in mcp-remote, a widely used connector, allowed remote code execution on the computer of anyone who connected it to an untrusted server. In September 2025 a malicious npm package posing as an email server quietly blind-copied every message it sent to its author.

Simon Willison named the pattern behind most of these the lethal trifecta: an agent with access to private data, exposure to untrusted content, and a way to send data out. Any two can be managed. All three together mean that anyone who can put text in front of the model, in an email, a support ticket, a product review or a web page, can try to make it send your data somewhere. Germany’s BSI used the GitHub case as a worked example in its January 2026 guidance on attacks against language models, and concluded that residual risk can remain even when every relevant countermeasure is in place. Give an MCP server the narrowest permissions that do the job, because the most hostile text it ever reads gets the same permissions you did.

In practice that means read-only tools by default and write tools behind an explicit confirmation, one server per trust boundary rather than one server that can do everything, dependencies pinned and reviewed rather than whatever the package registry serves today, and never a tool that runs arbitrary SQL or shell commands against production. How AI agents changed hacking covers the attacker’s side, and AI-generated code security covers the code these servers are increasingly written with.

How to decide

Start with the API. If you do not have a clean, documented, authenticated one, that is the project, and it pays off whether or not an AI model ever touches it. If you do, ask who will call your system through a model and what they need to do with it: read, or change things. Read-only makes a small, safe first server. Write access is a real project with a security review attached.

Then build the smallest server that answers the most common question, put it in front of real users, and read the logs. The tool calls will tell you what the model actually needs faster than any design document. The model half of that work is what our AI & Automation service covers; the deterministic half usually starts with Workflow Automation.

Sources

Checked September 2026. The protocol is revised often, so the specification links point at the current revision, 2026-07-28; the incidents are dated to when they were disclosed. The advice on when to build a server is ours.

Was this helpful?
Share this article
Related serviceAPI & IntegrationsRelated serviceAI & AutomationRelated packageWorkflow AutomationRelated workSearch with Maps APIRelated packagen8n Automation

— FAQ

Frequently asked questions

Not sure your system needs an MCP server?

Tell us what you want an assistant to do with it. We will tell you honestly whether that is an MCP server, an API, a workflow, or nothing yet.

Start a projectWhatsApp