MCP vs API vs Function Calling: What's the Difference?

These three terms get used as if you have to pick one, and in blog comments and standups they get swapped around almost at random. You do not have to pick one — they are three different layers of the same stack, and most real systems use all three at once. The confusion is worth clearing up precisely, because once you see how they nest, questions like "should we build an MCP server or just do function calling?" stop being either/or and start having actual answers.

We will define each term on its own, show the relationship with a side-by-side matrix, draw the line against two things they get confused with (RAG and plugins), and then get to the honest part: when MCP is worth the extra machinery and when it is not.

An API (application programming interface) is the oldest and most general of the three. It is simply the contract by which two pieces of software talk to each other — a REST endpoint, a GraphQL query, a gRPC method, a library function. When you call GET /bugs?since=7d and get JSON back, that is an API doing its job. Crucially, an API has nothing to do with AI. It is the capability that actually does the work: reads the database, charges the card, creates the ticket. Everything above it in this article is a way of letting a language model reach that capability. The API is the engine; the rest is wiring.

Function calling — also called tool use — is a feature of the model itself. You give the LLM a set of tool definitions (each with a name, a description, and a JSON schema for its arguments) inside a single prompt or application. The model does not run anything. What it does is decide: based on the user's request, it emits a structured call — the tool name plus arguments that satisfy the schema. Your code receives that call, executes it (usually against an API), and feeds the result back to the model. The key word is per-application: you hand-wire each tool into each app. If you have three apps that all need the same "create bug" tool, you define and maintain that tool three times.

The Model Context Protocol is an open standard — Anthropic open-sourced it in late 2024 — that sits on top of function calling. The problem it targets is the hand-wiring above. Without MCP, every application re-implements its own tool definitions, its own execution glue, its own auth. With MCP, you build one MCP server that exposes a typed set of tools (plus resources it can read and prompts it can offer) over a standard protocol. Then any MCP-compatible client — Claude, Cursor, VS Code, and a growing list of others — can connect, discover the available tools automatically, and call them. This is the one time we will use the popular analogy: MCP is the USB-C port for AI tools. One standard socket; plug in any client.

Read the matrix top to bottom and the nesting is clear. An API can be reused, but each new app re-wires it. Function calling adds the model's decision-making but is stuck inside one application. MCP is the only row that gets a true under both discovery and standardization — that is the entire point of it, and also the entire cost of it, as we will see.

Trace a single request through all three. A developer in Cursor types "pull the reproduction for the checkout bug and suggest a fix."

1. MCP already told Cursor, at startup, that a get_repro tool exists — that is discovery, done once via the standard.
2. Function calling is how the model acts on it: given the discovered schema, the model emits a structured get_repro({ id: "BUG-482" }) call.
3. The MCP client executes that call by asking the MCP server, which calls the underlying API (GET /bugs/BUG-482/repro), gets the session replay and console logs, and hands them back up the chain.

All three layers fired for one request, each doing its own job. Nobody replaced anybody.

Two more terms get pulled into this soup, so draw the lines explicitly.

RAG (retrieval-augmented generation) is about knowledge, not action. RAG fetches relevant text — from a vector store, a docs site, a wiki — and injects it into the model's context so the model can read it before answering. It does not do anything to the outside world. MCP is about action and live access: calling tools that change state or pull fresh data on demand. Simplest split: RAG reads; MCP acts. They compose happily — an MCP tool can be the retrieval step feeding a RAG pipeline.

Plugins (in the ChatGPT-plugin sense) were an earlier, vendor-specific attempt at the same job MCP now does — letting a model reach external tools. The difference is ownership: a plugin system is one company's proprietary format that only their client understands, so every provider needed its own. MCP is the open standard that generalizes the idea across clients and vendors, which is precisely why the ecosystem consolidated on it.

Here is the part the hype tends to skip. MCP does not let a model do anything it could not already do with plain function calling and an API. If your app hand-wires a tool, the model can call it just fine — no MCP required. So what does MCP actually buy you? Standardization and reuse. It matters the moment you want many agents or editors to use the same tools without rewiring each one. One MCP server, and Claude, Cursor, and VS Code all get your tools for free, with discovery and a consistent schema. If you only have a single application calling a single tool it controls, MCP is machinery you may not need — a direct function-call integration is less setup and fewer moving parts.

This distinction is not academic for us — it is a product decision we already made. BugMojo captures the evidence that makes a bug reproducible: the rrweb session replay, console logs, network requests, environment. That data is only useful if an AI agent can actually reach it while it is trying to fix the bug. We could have shipped a function-calling integration for one editor and called it done. Instead, BugMojo exposes its bug data via an MCP server, so any MCP-compatible agent — Claude Code, Cursor, VS Code — can pull a reproduction directly, rather than every team hand-wiring its own function-call integration into its own tool of choice.

That is the thesis of this whole article in one product choice: the capability (an API that returns a reproduction) already existed. MCP is what makes it reusable across every agent your team happens to run, without you maintaining N separate wirings. Standardization and reuse — exactly the thing MCP is for.

If you want the deeper background, our MCP developer's primer covers the protocol itself, how to build an MCP server walks through shipping one, and how AI agents fix bugs with MCP shows the end-to-end loop. For the actor doing the calling, see what is an AI agent.