MCP vs Function Calling: Which for Local Agents?

When you give a local agent tools, function calling and MCP are not competitors — they solve different layers of the same problem. Function calling is how a model decides "I should use a tool now" and returns a structured call (a tool name plus JSON arguments) instead of plain text; MCP (the Model Context Protocol) is an open standard that packages those tools and data into reusable servers so many agents can share them without bespoke glue. Use function calling for one app's built-in tools, and reach for MCP when the same tools must run across many agents.

In one line: function calling is how a model calls a tool; MCP is how you standardize and share what the tools are. They are not substitutes — they stack together.

What is function calling?#

Function calling (also called tool calling) is the pattern where you hand the model a set of tool definitions up front. A tool definition is usually a name, a one-line description, and a JSON schema for its arguments. When the model decides during a conversation that a tool is needed, it returns a structured call — a tool name and JSON arguments — instead of plain prose. Your app then actually runs that function and feeds the result back so the conversation can continue.

Put simply, the model is a chef and a function call is an order ticket that says "make this dish with these ingredients." The model never touches the stove itself. It just writes the ticket in the exact required format and hands it to the kitchen (your code). This is the core mechanism every modern agent uses to act. A common misconception: people assume the model executes the function. It never does — execution is always your app's job. The model only decides what to call and with which arguments.

What is MCP?#

The Model Context Protocol (MCP) is an open client-server standard for exposing tools and data to models. One MCP server wraps a capability (a filesystem, a database, an internal API) and advertises it in a standard way, so any MCP-compatible agent can attach to that server and use its tools without bespoke glue. The point is to write an integration once and reuse it across many clients.

By analogy, if function calling is a custom power socket you rewire for every app, MCP is a standardized socket. Build to the standard once and Claude Desktop, an IDE extension, or your own agent can all plug in the same way. A natural question is "why run yet another server?" The answer: once a tool is reused by two or more agents, the cost of re-implementing that integration N times exceeds the cost of running a single server.

When should you use which?#

If you are shipping a single app with a handful of tools, native function calling is the least moving parts. You never stand up or manage a server — you just define and run tools with the function-calling feature your model API already provides. Conversely, if you are building several agents, or want to pull in tools built by other teams or the community, MCP pays off by making those integrations portable.

The third option, ad-hoc prompting (scraping tool calls out of free text with a regex), is fast for throwaway scripts but brittle and hard to secure. A small formatting slip from the model breaks the parser, and without argument validation a dangerous input can execute as-is. Once you move past a prototype toward production, migrating to function calling or MCP is the safe path.

So do they compete, or work together?#

MCP and function calling are complementary, not competing — and the structure makes it clear. An MCP server advertises "here are the tools you can use right now," and the model still uses function calling to pick one and fill in its arguments. In other words, MCP does not replace function calling. It standardizes what the tools are so many agents can share them, while function calling still handles how they are invoked.

To sum up: inside one app, function calling alone is enough; the moment you need to reuse tools across many places, layer MCP on top. It is not an either/or choice — as scale grows, they naturally work together.

Note: the agent tooling ecosystem and the MCP spec are still young and moving quickly (as of mid-2026). Before you wire anything up, verify the details against each provider's current function-calling docs and the latest official MCP specification. This post is updated when the spec changes.