Function calling is the LLM-to-host layer where the model emits a tool call. MCP is the host to server layer that discovers and exposes those tools. They compose.
Picture ordering at a restaurant. Function calling is you telling the waiter, in a clear structured way, 'I want the pasta with no garlic.' MCP is the standardized kitchen-supply system behind the scenes. It lets the restaurant source ingredients from any vendor without redesigning the kitchen for each one. You still place your order no matter how the kitchen is stocked. And the supply system works the same whether you order pasta or pizza. They sit at different points in the flow. One is how the model voices a request, and the other is how the host reaches out to tools and data. They are different layers used together, not rivals replacing each other.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
MCP and function calling are easy to confuse because both involve tools. The common mistake is treating them as alternatives, where one replaces, deprecates, or subsumes the other. They do none of those things. They live at different layers of the agent stack and solve different problems.
Function calling answers the question, 'how does the model tell the host it wants to run a tool?' MCP answers a different question, 'how does the host find out what tools, files, and prompts are available in the first place, especially across multiple vendors?'
What function calling is
Function calling is a contract between the model and the host runtime. The host puts a tool schema into the prompt, typically as JSON Schema describing the function name, arguments, and return shape. The model emits a structured payload like { name: "search_docs", arguments: { query: "vector index" } } when it decides to invoke that tool. The host parses the payload, runs the underlying function, and feeds the result back into the next turn.
The model does not run anything. It only produces text that happens to be a well-formed tool call. The training objective makes this reliable. The model has seen enough examples to emit valid JSON matching the supplied schema. It has also learned to stop generating once the call is complete, so the host can take over. The host owns the entire execution side, including timeouts, retries, and whether to ask the user for permission before running a side-effectful call.
Function calling is format, not transport. There is no network and no protocol. It is only a convention for how the model serializes intent and how the host deserializes it. OpenAI, Anthropic, Gemini, and Mistral each ship a slightly different shape, but the idea is identical. One vendor wraps the call in a tool_calls array, another emits a tool_use content block, and a third uses a functionCall field. The semantics are the same.
Function calling does not answer where the tools come from. Function calling assumes the host already knows the full list of tools and their schemas. It says nothing about how that list got assembled. Every app shipping function calling in 2023 wrote custom wrapper code per integration: the Notion plug-in, the GitHub plug-in, the database plug-in, all hand-rolled. Each wrapper had to translate the vendor schema, manage credentials, and marshal results by hand. That custom per app problem is what MCP exists to fix. This is also why the option calling function calling 'deprecated' is wrong. It is still the universal model-facing surface, and nothing in MCP removes the model's need to speak it.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Concern | Function calling | MCP |
|---|---|---|
| Layer | LLM to host contract | Host to server protocol |
| Defined by | Each model vendor (OpenAI, Anthropic) | Open spec, vendor-neutral |
| Transport | Inside prompt and completion | JSON-RPC over stdio or HTTP |
| Primitives | Tool schemas, tool calls | Tools, resources, prompts |
| Reusable across apps | No, model-specific shape | Yes, one server runs in any host |
Real products, models, and research that use this idea.
- Claude Code ships a built-in MCP client and discovers tools from any registered server at session start. It then exposes them to Claude Opus 4.7 as tool_use entries.
- The MCP project's reference filesystem server and the vendor-maintained GitHub and Slack servers work as drop-in plug-ins shared across hosts.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you handle authentication when an MCP server talks to a private API?
Keep per-server credentials in the host config and use OAuth bearer tokens on the HTTP transport. Never let the model see the secret.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Picking the option that says MCP replaces or deprecates function calling. They sit at different layers, so the host speaks both at once.
60 second bullets to scan on the way to the call.
Which layer function calling sits at in the data flow
Which layer MCP sits at in the data flow
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.