MCP vs function calling: what's actually different?

“Why do I need MCP when my model already does function calling?” is the most common question people bring to MCP — and it rests on a category error. These are not two ways of doing the same thing. They sit at different layers, and almost every MCP setup uses both at once.

Two different layers

Function calling is a model capability. You send the model a list of tool definitions (name, description, JSON schema) alongside your prompt; the model replies with a structured request to call one of them; your code executes the call and feeds the result back. Every major provider ships a flavour of this — Claude’s tool use, OpenAI’s function calling, Gemini’s function declarations. It says nothing about where those tools come from, how they’re hosted, or how another application could reuse them.

MCP is a wire protocol that lives one layer down. It standardises how a client application discovers tools (tools/list), invokes them (tools/call), and how servers package tools, resources, and prompts behind a transport (stdio or Streamable HTTP). The model never speaks MCP. Your MCP client — Claude Desktop, Claude Code, Cursor, VS Code — fetches tool definitions from connected servers, hands them to the model as ordinary function-calling definitions, and routes the model’s tool-call requests back over MCP.

So the honest picture is a pipeline, not a rivalry:

model ⇄ (function calling) ⇄ MCP client ⇄ (MCP protocol) ⇄ MCP servers

Function calling is the last hop. MCP is everything before it.

Side by side

	Plain function calling	MCP
What it is	Model-side mechanism for structured tool requests	Open protocol for packaging, discovering, and transporting tools
Who defines the tools	You, inline in your application code	An MCP server — yours or someone else’s
Discovery	None — hardcoded list per app	Dynamic via tools/list; clients pick up changes
Reuse across apps	Copy-paste the definitions and handlers	Connect the same server to any MCP client
Distribution	Ship your app	Publish a server; users add one config entry
Beyond tools	Tools only	Tools, resources, prompts, elicitation, structured output
Extra moving parts	None	Server process, transport, client config
Token cost	Only the definitions you wrote	Every connected server’s definitions at init

When plain function calling wins

If you are building one application, with a handful of tools, that only that application will ever use — skip MCP. Define your tools directly in the API call, handle the execution loop yourself, and you’re done. No server process, no transport, no config files, no version skew between client and server. A support bot with three internal lookups, a script that calls one database — plain function calling is simpler, faster to debug, and has zero protocol overhead.

This is also the right choice when latency matters at the margin: an in-process function call will always beat a round trip through a subprocess or HTTP hop, even if the difference is usually milliseconds against a model call measured in seconds.

When MCP wins

MCP earns its extra machinery in three situations:

Reuse across clients. You wrote a tool that queries your issue tracker. With plain function calling it lives inside one app. As an MCP server, the same code works in Claude Desktop, Claude Code, Cursor, VS Code Copilot, and ChatGPT connectors — each needs only a config entry, not an integration.

The ecosystem. Thousands of MCP servers already exist for GitHub, Postgres, filesystems, browsers, and more, discoverable through the official registry (registry.modelcontextprotocol.io, live in preview). With function calling alone, every one of those integrations is something you rebuild by hand.

Team distribution. MCP turns “here’s my tools folder, wire it into your agent” into “add this line to your .mcp.json”. For a team standardising agent tooling — or a company exposing an internal API to every AI client employees use — a server is the packaging format. Since MCP moved to the Agentic AI Foundation under the Linux Foundation (December 2025), it is also the vendor-neutral bet: Anthropic, OpenAI, Google, and Microsoft all sit behind the same protocol.

The honest cost: tokens

MCP’s convenience has a price that too few write-ups mention. Every tool definition from every connected server is loaded into the model’s context at session start — whether or not the model ever calls it. A single large server can be brutal: a 106-tool server measured around 54K tokens just at initialisation. That’s context you pay for on every request, and it degrades tool selection too, because the model has to choose among dozens of near-duplicate options.

Plain function calling forces a discipline MCP makes easy to lose: you only pay for the tools you deliberately included. If you adopt MCP, keep that discipline anyway — connect few servers, prefer servers with fewer, better-designed tools, and disable what you don’t use. Task-shaped tool design matters more than protocol choice; the same trade-off shows up when wrapping existing APIs, which we cover in MCP vs OpenAPI.

Verdict

Stop comparing them as alternatives — function calling is the mechanism, MCP is the distribution standard, and in any MCP-connected app they run together. Choose plain function calling when one app owns a few private tools and nothing else will ever call them. Choose MCP when tools need to outlive a single application: multiple clients, existing ecosystem servers, or a team that should install your integration rather than rebuild it. And whichever you choose, count your tokens — the model reads every tool definition you connect, so fewer, better tools beat a bigger catalogue every time.

If you’re ready to put this into practice, the natural next step is building a small server of your own and connecting it to two different clients — that’s the moment the distinction stops being abstract.