MCP vs API: The Difference, and Where Function Calling Fits
September 30, 2026
MCP vs API is a false choice. They sit at different layers, and many MCP servers are built on top of an existing API.
Here's the short version:
- An API is a service's own interface. Stripe, GitHub, your internal billing system: each publishes endpoints that other software calls in a way that service decided on.
- MCP is a standard way for an AI application to discover and call capabilities. An MCP server lists its tools in one common format, and any compatible host can use them. Behind the server there's usually an ordinary API call.
- Function calling is the model-side mechanism. The model says "call this tool with these arguments," and something else runs it. MCP standardizes where those tool definitions come from and who runs them.
So the real question is "does this API need an MCP server in front of it, and who is that for?" If you need the basics of hosts, clients, and servers first, start with what MCP is. This post skips them.
Quick comparison: MCP vs API vs function calling
| API (e.g. REST) | MCP | Function calling | |
|---|---|---|---|
| What it is | A service's interface for other software | An open protocol between AI hosts and capability servers | A model feature for requesting tool calls |
| Who designs it | Each service, its own way | One shared spec | Each model vendor, in its own API format |
| Who calls it | Code a developer wrote | An MCP client inside an AI host | The model asks; your app or the vendor executes |
| How capabilities are found | Docs, or an OpenAPI description a developer reads | At runtime: the client asks the server to list them | You pass tool schemas in each request |
| Message format | Whatever the service uses (often JSON over HTTP) | JSON-RPC 2.0 | Vendor-specific request and response blocks |
| Primitives | Endpoints | Tools, resources, prompts | Tools only |
| Auth | Service's choice (API keys, OAuth, etc.) | OAuth 2.1-based for HTTP; environment credentials for local servers | Inherited from whatever runs the tool |
| Best for | Deterministic software-to-software calls | Making one integration usable across many AI apps | Wiring tools into one app you control |
What an API is, in this comparison
An application programming interface is a connection between programs. In the MCP debate, "API" usually means a web API: HTTP endpoints like GET /invoices or POST /issues, each with its own parameters, auth, and error codes.
APIs are designed per service. GitHub's API looks nothing like your CRM's. The OpenAPI Specification gives you "a formal standard for describing HTTP APIs," but each API still has its own shape, and a developer still writes the client code.
APIs are called by code you wrote. The caller knows in advance which endpoint it's hitting and why. Nothing in the loop decides on the fly. That's the part that changes when a model enters the picture.
What MCP adds on top of an API
Say you want an AI assistant to create GitHub issues. The GitHub API already does that. What it doesn't do is tell an AI host, in a format the host understands, "here is a tool called create_issue, here is what it's for, here is the schema for its inputs."
That's the layer the Model Context Protocol specification defines. The spec says tools let models interact with external systems, "such as querying databases, calling APIs, or performing computations." When a service already has an API, that API still does the work, and MCP is the standard wrapper around it.
Concretely, the protocol gives you:
Runtime discovery. A client sends a tools/list request and gets back each tool's name, description, and inputSchema. It then invokes one with tools/call. The tools section of the spec defines both, and servers can signal when their tool list changes. With a raw API, discovery is a human reading documentation.
One message format. Every request and response is JSON-RPC 2.0. A host that speaks MCP to one server speaks it to all of them.
Three primitives, each with a different controller. A plain API has no notion of who should trigger a call. MCP does, because the caller might be a model acting for a user:
| Primitive | Who decides when it's used (per the spec) | Rough API equivalent |
|---|---|---|
| Tools | The model ("model-controlled") | An endpoint that does something |
| Resources | The host application ("application-driven") | A read endpoint for a file or record, addressed by URI |
| Prompts | The user ("user-controlled"), often as slash commands | No direct equivalent |
Two standard transports. The transports spec defines stdio, where the host launches the server as a local subprocess, and Streamable HTTP, where each message is an HTTP POST to one endpoint. A stdio server may have no web API behind it at all, just your filesystem or a command-line tool.
One auth model for remote servers. Under the authorization spec, auth is optional. When an HTTP server uses it, the server acts as an OAuth 2.1 resource server and must not accept or pass along tokens issued for anyone else. Local stdio servers take credentials from the environment. With raw APIs, every service picks its own scheme.
No sessions, as of the current revision. The 2026-07-28 spec describes "stateless, self-contained requests." A server that needs state across calls returns an explicit ID the model passes into the next call.
MCP vs function calling
Both involve "tools," both use JSON Schema, and both end with a model asking for something to run. The difference is which side of the connection each covers.
Function calling is between your app and the model. OpenAI's function calling guide lays out five steps: send the model a request with tools, receive a tool call, "execute code on the application side," send the output back, and get a final answer. Anthropic's tool use docs describe the same loop: for client tools, Claude returns a tool_use block, your code runs it, and you return a tool_result. The model never runs anything itself.
MCP is between the host and the capability. It answers what function calling leaves open: where do the tool definitions come from, and who runs them? Without MCP, you hand-write every schema and the code behind it. With MCP, the host pulls schemas from a server with tools/list and forwards the model's choice with tools/call.
| Function calling alone | Function calling + MCP | |
|---|---|---|
| Where tool schemas come from | You write them in your app | The MCP server publishes them |
| Who executes a call | Your application code | The MCP server, via the host's client |
| Reusable in another AI app? | No, it's wired into yours | Yes, any MCP host can connect |
| Tied to one model vendor's format? | Yes | The server isn't; the host translates |
The model vendors have now built this bridge into their own APIs. OpenAI's Responses API has a remote MCP tool: it fetches the tool list from the server you name, and when the model picks one, "the API will make a request to the remote MCP server to call the tool." Anthropic's MCP connector does the same from the Messages API. As of September 2026 it's in beta, supports only tool calls from the MCP feature set, and needs a server exposed over HTTP. Local stdio servers can't connect directly.
One cost applies either way. OpenAI's guide says function definitions "count against the model's context limit and are billed as input tokens," and Anthropic prices the tools parameter as input tokens too. An MCP server with forty tools doesn't make those schemas free; you just didn't write them. OpenAI also suggests fewer than 20 functions available at the start of a turn, as a soft guideline.
Where a plain API is stronger
Skip MCP when no model is choosing what to call.
| Situation | Why the API alone wins |
|---|---|
| A nightly sync between two systems | The steps are fixed. A model adds latency, cost, and a chance of choosing wrong. |
| Payment or billing logic | You want exact, tested code paths, not a model picking arguments. |
| High-volume backend traffic | A host, a client, and a model are overhead a direct call doesn't need. |
| An integration only your own app uses | Function calling with a few hand-written schemas is simpler than running a server. |
If the job is wrapping an existing service, that service needs an interface the server can reach. A tool handler doesn't always wrap anything, though: it can compute a result, query a database, or run your own business logic directly.
Where MCP is stronger
MCP earns its place when the caller is an AI host you don't fully control, or many of them.
| Situation | Why MCP wins |
|---|---|
| You want your service usable in several AI apps | Build one server instead of one integration per app. |
| Users add integrations themselves | They paste a URL or a command into their host's config, with no code. |
| The model needs to choose among many actions | Tools arrive with names, descriptions, and schemas the model can reason over. |
| You need files, records, or reusable prompts, not just actions | Resources and prompts cover what function calling doesn't. |
| Remote access with delegated user auth | Servers that use auth follow the same OAuth 2.1-based flow. |
The spec also says there SHOULD always be a human in the loop who can deny tool invocations. It admits it can't enforce that at the protocol level, so what you actually see depends on your host.
How to decide
Three questions settle most cases:
- Is a model choosing what to call? If no, use the API directly. If yes, keep going.
- Will more than one AI app need this? If only your app will, function calling with hand-written schemas is enough. If several hosts should use it, or users will add it themselves, build an MCP server.
- Does a good MCP server already exist? Check before you build. Many vendors publish their own, and our guide to MCP servers covers how to judge them.
If the answer is "build one," most of the work is wrapping calls you'd make to the API anyway. We walk through that in how to build an MCP server.
And if your gap is really "the AI doesn't know our process," neither MCP nor an API fixes that. That's an instruction problem, covered in Claude Skills vs MCP.
If you just want the working version
Plenty of people searching "MCP vs API" aren't building either. They saw someone connect Claude to a database or a CRM and want the same. The honest answer involves config files, credentials, and transports, and that's where most attempts stop.
Taku is an AI-native desktop workspace aimed at that gap: you mirror an AI app, skill, or workflow someone already got running, then run it, remix it, and keep it, instead of rebuilding their integration. Taku is in Beta, and the Mac app is available now.
Key points
- An API is one service's interface. MCP is a shared protocol AI hosts use to discover and call capabilities that usually wrap APIs.
- MCP adds runtime discovery, one JSON-RPC format, three primitives with different controllers, standard transports, and OAuth 2.1-based auth for HTTP servers.
- Function calling is how a model asks for a tool. MCP standardizes where the tool comes from and who runs it.
- Use a plain API when no model is choosing. Use MCP when several AI apps, or their users, need the same integration.
FAQ
Is MCP an API?
Not in the usual sense. MCP is a protocol: a standard that defines how any AI host and any capability server talk. A given MCP server does expose an interface, but it's one every compatible host already knows how to use, rather than a service-specific design.
Does MCP replace REST APIs?
No. Many MCP servers call a REST or other API behind the scenes. MCP replaces the custom glue each AI app would otherwise write for that API, not the API itself.
What's the difference between MCP and function calling?
Function calling is the model feature: the model outputs a structured request to use a tool, and your app or the vendor runs it. MCP is the protocol that supplies tool definitions and executes the calls through a server. A host typically uses function calling to let the model pick an MCP tool.
Is MCP more secure than calling an API directly?
Not automatically. MCP defines an OAuth 2.1-based flow for remote servers and says a human should be able to deny tool calls, but it can't enforce that. The host decides. A server holding your credentials deserves the same trust check as any software you install.
Can I turn my existing API into an MCP server?
Yes, and that's a very common kind of MCP server. You describe each operation as a tool with a name, description, and input schema, and the handler calls your API. The build guide linked above walks through it.