MCP vs Function Calling: How They Actually Differ

MCP vs function calling is not a fight — they sit at different layers. Function calling is the model deciding which tool to call and with what arguments. MCP (the Model Context Protocol) is the wire format and lifecycle that serves those tools to any client. One is a model capability; the other is an integration standard. In practice you use them together, and most confusion about "mcp vs function calling" disappears once you see that.

The short version: the model still does function calling under the hood. MCP just changes where the tool definitions come from and how they get wired in. If you've written an OpenAI or Anthropic tool schema by hand, MCP is what stops you from doing that for the fiftieth integration.

What function calling actually is

Function calling is the model emitting a structured request to invoke a tool you defined. You hand the model a list of function schemas (name, description, JSON-Schema parameters); it reads the user's intent and returns a JSON blob saying "call get_weather with {city: "Tokyo"}." Your code runs the function and feeds the result back.

That's the whole mechanism, and it hasn't fundamentally changed since 2023. The model never runs anything itself — it only proposes a call. Execution, auth, and error handling are entirely on you. Function calling is a model feature baked into the API you're already using.

The catch is that you write and maintain every schema, every dispatcher, and every credential path yourself. Ten tools is fine. A hundred tools across a dozen services, kept in sync as those APIs change, is the part nobody enjoys. That maintenance tax is exactly the gap MCP was built to close.

What MCP actually is

MCP is a standard for serving tools to any AI client over a defined protocol, so you write the integration once instead of per app. An MCP server exposes a set of tools (plus resources and prompts) that any MCP-compatible client — Claude Desktop, Cursor, your own agent — can discover and call. The client asks the server "what tools do you have?", the server answers, and the client hands those definitions to the model.

Under the hood the model still does function calling on those definitions. MCP's job is the plumbing around it: discovery, a stable schema, transport, and lifecycle. If you want the ground-up version, what is an MCP server walks through it.

Two things worth internalizing. Many MCP servers run locally over stdio — the server is a subprocess on your machine, not a hosted endpoint — while others are exposed over HTTP for remote use. And there's a split between official (first-party) servers, built by the vendor whose product they wrap, and community builds wrapping someone else's API. Both matter when you pick one, because they differ in trust and in where the code actually runs.

The layers, side by side

The cleanest mental model: function calling is the decision, MCP is the delivery. Here's how the responsibilities split.

Concern	Function calling	MCP
Layer	Model capability	Integration standard
Who defines the tools	You, by hand, per app	The MCP server, once
Who picks the tool	The model	The model (unchanged)
Who executes it	Your code	The MCP server
Reuse across clients	None — rewrite per app	Any MCP client, no changes
Discovery	Static list you pass in	Client queries the server at runtime
Where it runs	In your app process	A local stdio subprocess or a remote HTTP endpoint

Read the table top to bottom and the relationship is obvious: MCP doesn't replace the "model picks a tool" step. It replaces the you-wrote-all-this-yourself step. This is the same layering argument as MCP vs API, just from the model's side of the wire.

When to use which

Use raw function calling when you have a handful of tools, tight control needs, or a single app. Use MCP when you want to reuse integrations across clients or pull in tools you didn't write. They are not mutually exclusive — an MCP client is doing function calling on the server's tools.

Reach for hand-written function calling when: you have 5–10 bespoke tools; the logic is internal and app-specific; you need to shape schemas or post-process results precisely; or you don't want a separate process in the loop. There's no reason to add MCP to a small, closed toolset.

Reach for MCP when: you want the same GitHub, Postgres, or Slack integration to work in Cursor and Claude and your own agent; you'd rather adopt a maintained server than write and babysit another API wrapper; or you want tools to be swappable without touching app code. Browse the best MCP servers or the full capabilities index to see what's already built before you write anything.

The trap: MCP doesn't fix the tool budget

Because MCP makes adding tools trivial, it makes overloading the model trivial too — and function calling degrades well before you'd guess. Cursor, for example, warns that it works best under roughly 40 active tools total; past that, the model's tool selection gets sloppy regardless of how the tools were served.

Here's the part people skip. A single MCP server often exposes a whole cluster of tools at once, so it doesn't take many servers to crowd out that budget. Every tool definition, MCP-served or hand-written, eats the same context and competes for the model's attention. Adding a server is easy; the tool count it brings with it is the thing to watch.

So the discipline is the same in both worlds: expose the fewest tools that do the job, with clear names and descriptions. MCP just removes your excuse for having too few — and hands you an easy way to have far too many.

The takeaway

MCP vs function calling is a category error dressed up as a comparison. Function calling is how a model selects and shapes a tool call; MCP is how tools get published so any client can offer them for selection. You almost never choose one over the other — you write function schemas by hand for a small internal toolset, and you adopt MCP the moment you want reuse, and both run through the same model mechanism. Pick based on how many tools you have and how many places need them, not on which acronym sounds newer.