AI
MCP vs Function Calling: How AI Agents Use Tools
August 20268 min read
Function calling is a feature of the model API: you pass JSON tool schemas and the model returns a structured call your code runs. MCP is an open protocol that puts tools behind a reusable server any compatible client can connect to. They operate at different layers and complement each other rather than compete.
No. When an MCP client connects to a server, it hands the discovered tool schemas to the model as ordinary function-calling tools. The model still uses function calling to choose which tool to invoke, so MCP builds on top of it rather than replacing it.
Your application does. The model only returns the tool name and arguments; it never runs code itself. Your handler performs the real action, such as a database query or an API request, then returns the result so the model can continue its answer.
Use MCP when the same tools need to be reused across several applications or shared with others. If your tools live inside and serve only one app, plain function calling is simpler. MCP shines as a distribution layer, not for a single-app integration.
An MCP server can expose tools, resources, and prompts. Tools are actions the model can invoke, resources are context data such as files or records, and prompts are reusable interaction templates. Clients discover these primitives before using them.
Key Takeaway
MCP vs function calling compares two layers of AI tool use. Function calling is a model API feature: you send JSON tool schemas, the model returns a structured call, and your code runs it. Model Context Protocol is an open standard that puts tools behind a reusable server any compatible client can connect to. They are complementary, not rivals.
Both function calling and the Model Context Protocol let a large language model use external tools, yet they solve different parts of the problem. One is a feature of the model API you already call; the other is a protocol that sits above it. Confusing the two leads to bad architecture decisions.
This post walks through what each one is, the real differences, and why the honest answer to MCP vs function calling is that you usually want both. Under the hood, an MCP client still relies on the model's function calling to pick which tool to run.
Function calling, which Anthropic calls tool use, is a capability of the model API. You describe each tool as a JSON schema with a name, a description, and typed parameters, then pass that list in your request alongside the user message. The model reads the schemas and decides whether a tool helps answer the prompt.
When it decides yes, the model does not run anything. It returns a structured tool call naming the function and its arguments. Your application executes the real work, a database query or an HTTP request, and sends the result back so the model can finish its answer. That round trip is the whole mechanism.
MCP is an open standard, introduced by Anthropic in late 2024, for connecting AI applications to external systems. Instead of wiring tools into one app, you put them behind an MCP server. Any MCP-compatible client, such as Claude Desktop, an IDE, or your own app, can connect and use them. Its own docs compare it to a USB-C port for AI.
The architecture is client-server over JSON-RPC. A host application creates one MCP client per server it connects to. A server can expose three kinds of primitives: tools, which are actions the model can invoke; resources, which are context data like files or records; and prompts, which are reusable templates. The client discovers what a server offers, then calls it.
How function calling and MCP compare across the aspects that drive architecture choices.
| Aspect | Function calling | MCP |
|---|---|---|
| What it is | A model API feature for tool use | An open protocol for connecting tools |
| Reusability across apps | Per-app wiring, tied to one API | Write once, reuse across clients |
| Who runs the tool | Your application code | An MCP server the client calls |
| Standardized | Per provider, not shared | Yes, one open JSON-RPC standard |
| Best for | A few tools in one app | Sharing tools across many apps |
If you find yourself copying the same tool integration into a second application, that is the signal to move it behind an MCP server so both apps share one implementation.
The layers are the key. Function calling is how a single model turns intent into a structured call. MCP is how tools are packaged and shared so many clients reuse them without rewiring. Here are the differences that actually matter in practice.
The common myth is that MCP replaces function calling. It does not. When an MCP client connects to a server, it fetches the list of available tools and hands their schemas to the model as ordinary function-calling tools. The model still uses function calling to decide which one to invoke.
The difference is who wrote and hosts the tool. With plain function calling you author the schema and the handler inside your app. With MCP the schema comes from a server someone else can maintain, and the client routes the model's chosen call to that server. Function calling is the decision step; MCP is the distribution layer.
MCP does not remove the need to think about tool design. A server that exposes dozens of vague tools still confuses the model, because selection still happens through function calling and its token and accuracy limits.
Pick based on reuse and reach, not hype. If tools live in and serve exactly one application, plain function calling is simpler and has fewer moving parts. If the same capabilities should be available to several clients or shared with others, an MCP server pays for itself.
MCP vs function calling is not a contest but a stack. Function calling is the model-level mechanism that turns a prompt into a structured tool call your code executes. MCP is the open protocol that makes those tools reusable across clients. Reach for function calling when tools serve one app, and for MCP when they should be shared.