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 that 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, the other is how the host reaches out to tools and data. The correct answer is that 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.
This question trips up a lot of candidates because both MCP and function calling involve tools, and both arrived in the same 2024-2025 wave of agent tooling. The trap baked into the options 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?'
This deep dive walks through both layers, shows why three of the four options are wrong, demonstrates how the layers compose in a real stack like Claude Code, and gives you the language to explain the boundary cleanly in an interview.
What function calling actually 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 actually run anything. It only produces text that happens to be a well-formed tool call. The training objective is what makes this reliable: the model has seen enough examples to emit valid JSON matching the supplied schema, and 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.
The key insight is that function calling is format, not transport. There is no network and no protocol. It is just 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, a third uses a functionCall field; the semantics are the same.
Where it stops short is the question of 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 bespoke 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 bespoke per app problem is exactly 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, then exposes them to Claude Opus 4.7 as tool_use entries.
- Anthropic's MCP server registry exposes filesystem, GitHub, Postgres, and Slack servers 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?
Per-server credentials in the host config; 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.