MCP vs Function Calling
They're not alternatives — they're different layers, and adding one doesn't remove the other. Function calling is how a model requests that one specific action run, with specific arguments. MCP is how your application discovers what actions exist to request in the first place, across many tools, without writing custom code for each one. A model connected through MCP still calls a tool exactly the way it calls any other function. MCP adds a layer underneath that call; it doesn't replace it.
What function calling does
You describe a function — a name, a description, and the arguments it takes — and the model can decide to call it. Your code runs the actual function and sends the result back. That's the entire mechanism, whether the function is something you wrote yourself or something an MCP server handed the model a definition for. The Function Calling page covers writing one that actually works.
What MCP does
MCP is a shared protocol — a set of rules both sides agree to follow — for connecting an AI application to external tools and data, so a tool built once can work with any MCP-compatible application without pairing-specific integration code. It solves a discovery-and-connection problem, not a calling problem — the MCP page's own walkthrough of asking about your pull requests shows this precisely: MCP is what makes finding and connecting to the GitHub tool possible without custom code; the model still requests it with an ordinary tool call, the exact same step as any other function.
Side by side
| Function calling | MCP | |
|---|---|---|
| Problem it solves | How the model requests one specific action | How an app discovers and connects to tools at all |
| Who calls the tool | The model, via a tool call | Still the model, via the same tool call — MCP doesn't change this step |
| Adding a new tool | Write the function and its schema yourself | Connect to an existing MCP server, or write one once |
| Reusing a tool across apps | Rewrite the integration for each application | Build the server once; any MCP-compatible app can use it |
| Needed for one in-house tool, one app | Yes — this is all you need | No — the connection layer adds nothing here |
Which one your problem calls for
Function calling alone is enough when you have one specific tool that only your one application will ever call — an internal "look up this customer's order" function used by a single support bot, say. There's nothing to discover and no second application to share it with, so the extra connection layer would add cost without solving a problem you actually have.
Add MCP once the same tool or data source needs to be reachable from more than one AI application, or the set of tools you connect to changes often enough that rewriting integration code each time is real, recurring cost. A GitHub integration meant to work inside Claude, ChatGPT, and a code editor at once is the textbook case: build one MCP server, and every one of those applications can use it through ordinary function calling underneath, with no pairing-specific code for any of them.
In this guide
FAQ
If an application already uses MCP, does it still need function calling at all?
Yes — MCP doesn't replace it. An MCP server supplies tool definitions; the model still requests one of them with an ordinary tool call, the same mechanism it would use for any function you'd written yourself. MCP changes how the tool got discovered and connected, not how it gets called.
Does adding MCP make a single in-house tool easier to call?
No. MCP's value is in discovery and reuse across tools and applications — for exactly one tool used by exactly one application, that machinery has nothing to add. Plain function calling is simpler and does the same job with less to maintain.