MCP vs API: What's the Difference, and Do You Need Both?

An API is a contract written for developers’ code. MCP, the Model Context Protocol, is an open protocol that lets AI assistants discover and use your systems at runtime. In the MCP vs API question, many businesses need both, because an MCP server usually wraps an API that already exists. The API stays the source of truth and the MCP server is the AI-facing layer on top.

This guide is for a business that already has an API, or runs systems that do, and has just been asked whether to build an MCP server. It covers how the two differ, where MCP sits in the stack, how it compares with function calling, which assistants can connect today, and how to decide. If you want the basics first, start with our guide to what an MCP server is.

MCP vs API at a glance

The two solve different problems for different callers. An API lets one piece of software talk to another, with the integrating developer reading the documentation and writing the calls. MCP lets an AI assistant ask a server what it can do and then use it, without anyone writing a bespoke client for that assistant.

Aspect	API	MCP server
Built for	Developers’ code	AI assistants and agents
How a caller learns what it can do	Documentation or an OpenAPI spec	It asks the server at runtime with tools/list
Message format	REST or GraphQL over HTTP	JSON-RPC 2.0 over stdio or Streamable HTTP
Authentication	Whatever your API uses	Optional; OAuth 2.1-based on HTTP, environment credentials on stdio
Who writes the client	Each integrator	Any MCP-compatible assistant

Discovery. Under the MCP specification, a client lists a server’s tools with a tools/list request. Each tool comes back with a name, a description and an input schema written in JSON Schema. The server can also notify the client when its tool list changes. An assistant reads those descriptions and decides which tool fits the task. With a conventional API, a developer reads the docs once and hard-codes the calls.

Message format. The current specification uses JSON-RPC 2.0 messages. It defines two transports: stdio, for a server running next to the client, and Streamable HTTP, where each message is an HTTP POST to a single MCP endpoint. The older HTTP+SSE transport was deprecated in 2025.

Authentication. Authorization is optional in the specification and applies to HTTP transports. It is based on OAuth 2.1, which is still an IETF draft. A server must implement OAuth 2.0 Protected Resource Metadata (RFC 9728) and must check that a token was issued for it. A stdio server takes its credentials from the environment instead.

How an MCP server sits on top of your API

An MCP server is a translator between an AI assistant and the API you already run. The assistant never touches your database. It talks to the server, and the server calls your API, which applies your business rules as it always has.

The chain looks like this:

1. Host. The AI application a person uses, such as Claude or GitHub Copilot.
2. MCP client. The part of the host that speaks the protocol.
3. Your MCP server. It exposes a chosen set of tools, resources and prompts.
4. Your existing API. It validates, authorises and applies the rules.
5. Your database or system of record.

The server translates, and your API keeps the rules. That split is why a well-built MCP server is thin. It should not copy your pricing logic or your permission checks, because two copies drift apart. It calls the API and lets the API refuse what it would refuse for any other caller.

The specification gives servers three kinds of primitive, covered in the protocol overview.

Tools are actions the assistant can invoke. Per the tools specification, a tool can query a database, call an API or perform a computation. “Look up an order” or “create a draft invoice” are typical examples.

Resources are data the assistant can read as context, such as a document, a record or a report.

Prompts are reusable templates a server offers, so a common task such as summarising an account starts from a tested instruction.

Most business servers are mostly tools, with a few resources. For a fuller walkthrough of designing one, see how to build an MCP server.

MCP vs function calling

Function calling and MCP both let a model use outside capabilities, but they work at different levels. Which one you need depends on how many apps and assistants must reach the same capability.

Anthropic describes tool use, also called function calling, as letting Claude call functions you define, and says client tools run in your application. OpenAI has a function calling guide for its own models.

This is our reading, not vendor wording. Function calling is defined per application and per model provider. You pass the function schemas in each request, the model asks to call one, and your own code runs it. MCP is a shared protocol. You publish the capabilities once on a server, and any compliant client can discover and use them.

In practice, that gives two rules of thumb:

• One application, one model. If you control the app and it needs a few fixed actions, function calling is simpler. You write the schemas and the code that runs them, and there is no extra server to host.
• Many assistants, or tools outside your app. If different assistants, or your customers’ assistants, need the same capabilities, an MCP server avoids rewriting the schemas and glue for each of them.

The two also combine. An application can use function calling with a model and still give that model access to tools hosted on MCP servers.

Which AI tools can connect to an MCP server today?

As of November 2026, the major assistant and developer platforms below can connect to MCP servers. This list reflects each vendor’s documentation at that date, and support changes quickly, so check the linked pages before you commit.

• Claude. Anthropic supports custom connectors using remote MCP on Claude, Cowork and Claude Desktop. Developers can also use the MCP connector in the Messages API.
• OpenAI. OpenAI documents remote MCP servers that models can reach over the internet through the Responses API.
• Microsoft Copilot Studio. Microsoft says Copilot Studio currently supports MCP tools and resources.
• GitHub Copilot. GitHub lists MCP support in VS Code, Visual Studio, JetBrains IDEs and others.

Who steers the standard matters for a long-lived investment. Anthropic introduced MCP on 25 November 2024 as an open standard. On 9 December 2025 it donated the protocol to the Agentic AI Foundation, co-founded by Anthropic, Block and OpenAI. Anthropic said the governance model would remain unchanged.

Do you need an MCP server if you already have an API?

The honest answer is sometimes. Three situations cover most businesses.

Your API is enough

Stay with your API if one application you control calls one model for a few fixed actions. Say an internal tool asks a model to classify a ticket and then update its status. Plain function calling covers that. You define the functions, your code runs them against your API, and an MCP server would add something to host without adding reach.

You need an MCP server

Build one when you want people to work with your system from inside an assistant. Examples are staff who already work in Claude and want to ask about orders or accounts without switching tabs. Another is wanting several assistants to reach the same system. A third is being a software vendor whose customers are asking whether your product works with their AI assistant. In that last case a single MCP server gives every compliant assistant the same way in.

You need both

This is the setup we would recommend for most businesses with a working API. Keep the API as the source of truth for rules and data, and add the MCP server as a thin AI-facing layer. The layer should expose a narrower, safer set of actions than the API does. Your API might have dozens of endpoints, including admin and bulk operations. An assistant probably needs five or six of them, such as search, read and create a draft. Leave out delete, bulk update and anything that moves money until you have a reason and a control for it.

That narrowing is a design decision, and it is where much of the value of an MCP server sits. A model given the whole API surface has more room to pick the wrong action. A model given six well-described tools has less.

What changes for security when an AI calls your systems

A person using your API knows what they clicked. An AI assistant chooses actions from text, so the security model needs a few extra habits. The MCP project’s security best practices cover most of them.

• No token passthrough. The guidance says “Token passthrough is explicitly forbidden”. The server must not accept a token and forward it to your API unchecked.
• Accept only tokens issued for your server. Under the authorization specification, a server must validate that a token was issued for it as the audience.
• Get consent for proxy servers. A server that fronts a third-party API risks the confused deputy problem, and the best practices say such proxy servers must implement per-client consent.
• Ask for minimal scopes. The guidance says to avoid wildcard scopes. Give the assistant the access its tools need and nothing more.
• Treat tool descriptions as untrusted. The specification overview says to consider tool descriptions untrusted unless they come from a trusted server. This matters most if your assistants connect to third-party servers as well as yours.
• Keep a human in the loop. The tools specification says there should always be a human able to deny tool invocations.

Two habits from ordinary API work still apply, and they are our recommendations rather than quotes from the specification. Validate every input on the server, because the model’s arguments are only as trustworthy as the text that produced them. And rate limit, because an agent in a loop can call a tool far more often than a person would.

What it costs to add MCP to an existing API

Adding an MCP server to a working API is usually a contained job. CodeLeap’s MCP server development starts from £5,000 (about $6,500), at a fixed price agreed before we start. What moves the price is the number of tools, how many systems sit behind them, and how involved the authentication is.

If your API is missing or messy, that is the bigger job. An MCP server can only be as good as the API it calls. Inconsistent endpoints, undocumented behaviour or no usable auth all need fixing first, and the server inherits whatever is left. Our API integration guide covers how to connect systems properly, and our systems integration service handles the build when the API work comes first.

If the assistant is meant to take actions on its own over several steps, you are building toward an agent. Our guide to what an AI agent is explains the difference, and our AI agents and automation work covers building them.

A sensible next step

Write down the system you would want an assistant to reach, and the five or six actions you would let it take. If you can name those, you can scope a server. If you cannot, you probably do not need one yet.

If you want a second opinion on whether your API is enough, or what a thin MCP layer would involve, our MCP server development service starts from £5,000 (about $6,500). Book a call and we will tell you straight if plain function calling does the job.