MCP vs function calling vs APIs
"MCP or function calling?" is a common question, but they work at different layers. Function calling is how a model asks for an action. MCP is how an application finds out which actions exist and runs them. An HTTP API is usually what does the work underneath.
Three layers, not three rivals#
- Your API (REST, GraphQL, a database) does the actual work. It knows nothing about models.
- Function calling (often called tool use) is a feature of LLM APIs: the application passes the model a list of function names, descriptions and JSON Schemas, and the model replies with the name and arguments of the one it wants to call. The application runs it.
- MCP standardises the part in between: how an application discovers tools from a server (
tools/list), calls them (tools/call) and gets results back, over stdio or HTTP.
How they fit together#
The MCP architecture docs describe the flow. The host application connects to each MCP server through a client, fetches its tools and combines them into a tool registry that the language model can see. When the model decides to use a tool, the application intercepts that tool call, routes it to the right MCP server, and passes the result back to the model.
So in a typical setup the model still uses its provider's function-calling feature. MCP is what fills that function list, and what carries the call to the code that runs it.
Side by side#
| HTTP API | Function calling | MCP | |
|---|---|---|---|
| What it is | Your service's interface | An LLM API feature | An open protocol between AI apps and servers |
| Who defines the tools | n/a | The application developer, in code, per app | The server author, once, for any MCP host |
| Discovery | Docs, OpenAPI | Hard-coded in the app | tools/list at runtime |
| Where the code runs | Your service | Inside the app | In the MCP server (local process or remote) |
| Reuse across apps | Yes, with glue code | Per app | Any MCP-compatible host |
| Also offers | n/a | n/a | Resources and prompts, auth guidance for HTTP |
Which do you need?#
- One app, a handful of actions, you control the code: plain function calling is the simplest option. There's no extra process to run.
- You want your service usable from many AI apps (editors, desktop assistants, agents): build an MCP server once instead of an integration per app.
- You already have an OpenAPI document: you can draft MCP tool definitions from it with the OpenAPI → MCP converter, then tighten names and descriptions with the linter.
Whichever you choose, the tool definitions look almost the same: a name, a description and a JSON Schema. Good descriptions matter in both, because that's all the model sees.
Frequently asked questions#
Does MCP replace function calling?
No. In the flow the MCP architecture docs describe, the model still decides to call a tool, and the application routes that call to an MCP server. MCP standardises discovery and execution; it doesn't change how the model picks a tool.
Is MCP slower than calling my API directly?
An MCP server adds a hop between the app and your API. For stdio servers that hop is a local process; for remote servers it's an HTTP request. Whether that matters depends on your use case. We don't have benchmark data to quote.
Can I expose the same functions both ways?
Yes. The definitions are near-identical (name, description, JSON Schema), so many teams keep one source of truth and generate both.