If MCP lets an AI use tools, and function calling also lets an AI use tools, which one do you actually reach for? The honest answer is that they are not really competitors, and choosing wrongly mostly wastes effort rather than breaking anything. Here is what each one is, the real difference underneath, and a decision rubric you can apply in about thirty seconds.
Function calling in one paragraph
Function calling (Anthropic calls it tool use, OpenAI calls it function calling, same idea) is built into the model API. You send the model a list of functions with their JSON schemas, the model decides which to call and with what arguments, and replies with a structured request like "call get_weather with city=Paris". Your code runs that function and sends the result back. The tools live inside your application, defined in your code, called in your loop. Nothing else is involved.
MCP in one paragraph
MCP (the Model Context Protocol) moves those tools out of your app and into a standalone server that speaks a standard protocol. Any MCP-compatible client - Claude Desktop, Cursor, your own agent - can connect to that server, discover its tools, and call them. The tool is defined once, in the server, and reused everywhere. The client app does not need to know anything about the tool ahead of time; it asks the server what is available at runtime.
The one difference that matters
Everything else follows from a single distinction: where the tool lives.
With function calling, the tool lives inside one application, coupled to one model's API format. With MCP, the tool lives in a separate, reusable server that any client can talk to. That is the whole thing. Coupling versus reuse. Once you see it that way, the tradeoffs are obvious:
- Setup cost: function calling is just code in your app. MCP is a separate process and a protocol to learn. Function calling wins on getting started.
- Reuse: a function lives in one codebase. An MCP server is used by every client at once. MCP wins when more than one app needs the same tool.
- Portability: function-calling schemas differ per provider, so switching models means rewriting them. MCP is provider-agnostic, so the server does not change when you swap the model behind the client. MCP wins on avoiding lock-in.
- Governance: a function is tested and deployed with your app. An MCP server is versioned, tested, and updated on its own. MCP wins when tools need to evolve independently.
They actually work together
Here is the part the "X vs Y" framing hides: MCP does not replace function calling, it usually rides on top of it. When an MCP client surfaces a server's tools to the model, it typically presents them through the model's own tool-use mechanism. The model still emits a structured tool call the same way it always does. MCP is the standard for where the tools come from and how they are discovered; function calling is still the mechanism by which the model asks to use one. You are rarely choosing one instead of the other at the model layer; you are choosing how your tools are packaged.
The decision rubric
Skip the feature matrix. Answer three questions.
Pick plain function calling if: you have one application, a handful of tools, and one model. A prototype, an MVP, a script with two or three custom functions only your app uses. Setting up an MCP server here is overhead you do not need. Keep the tools inline and move fast.
Pick MCP if: the same tool needs to work across multiple clients (Claude Desktop and Cursor and a Slack bot and a pipeline), or you want tools you can version and update without redeploying every app, or you want to stay portable across AI providers, or you simply want to use the large ecosystem of existing servers rather than reimplementing filesystem or GitHub access yourself.
Use both if: you are building a real product. A common shape is core, app-specific logic as inline function calling, plus MCP servers for the reusable, cross-cutting capabilities (files, search, your database). There is no rule that says you must commit to one.
Three worked examples
A weekend chatbot that looks up the weather. One app, one tool, one model. Function calling. An MCP server would be three extra moving parts for zero benefit.
A "notes" tool you want in both Claude Desktop and your own agent. The moment the second client appears, inline function calling means writing the tool twice. Build it as one MCP server and connect both. This is the textbook MCP case.
A SaaS app exposing its capabilities to whatever model the customer prefers. Customers want it to work with Claude today and something else next quarter. Provider-specific function schemas would lock you in. An MCP server keeps the integration stable while the model behind it changes. MCP, clearly.
What about MCP vs a plain REST API?
People ask this next, so: a REST API is for software talking to software with a fixed, documented contract. MCP is for an AI client to discover capabilities at runtime and for a model to reason about which to use. They overlap, but MCP adds the discovery and self-description that lets a model pick a tool it was not hard-coded to know about. If a human developer is wiring two systems together with a known contract, REST is fine. If an AI needs to find and use tools dynamically, that is what MCP adds.
Takeaways
- The only difference that matters: function calling keeps tools inside one app; MCP puts them in a reusable server any client can call.
- They are not rivals. MCP is usually surfaced through the model's function-calling mechanism. You are choosing tool packaging, not model behavior.
- Use function calling for one app, few tools, one model. Use MCP for reuse across clients, provider portability, or independent versioning.
- Real products often use both: inline functions for app-specific logic, MCP servers for shared capabilities.
- If you are weighing MCP against a plain REST API, the thing MCP adds is runtime discovery and self-description for the model.