Function calling spans the LLM-to-host boundary; MCP spans the host to tool boundary. Different layers, used together, never in competition.
Picture an office with three people: a manager, an assistant, and a contractor. The manager (the LLM) tells the assistant 'book me a flight' in a precise, agreed-upon phrasing. That precise phrasing is function calling. The assistant (the host app) then calls the travel agency over a standard phone line that every agency understands. That standard phone line is MCP. The manager never dials the agency directly, and the agency never hears the manager. Each boundary has its own protocol. The manager to assistant boundary uses one shape; the assistant to agency boundary uses another. They stack on top of each other, so swapping the phone line does not change how the manager talks, and swapping the manager does not change how the assistant dials out.
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 is really a layering question dressed up as a comparison. The interviewer wants to know whether you can place each protocol at its boundary and explain why they stack instead of compete. Candidates who have only read headlines tend to say something like "MCP is Anthropic's function calling," which collapses two distinct layers into one and gets the architecture wrong. The reason this confusion is so common is that both arrived in the same 2024-2025 wave of agent tooling, both involve the word "tool," and both let a model end up running code it did not write. Surface-level overlap hides a deep structural difference.
The clean mental model is three boxes in a row: the LLM, the host application that embeds it, and the external tool or data server. Two gaps separate those three boxes. Function calling owns the inner gap, between the LLM and the host. MCP owns the outer gap, between the host and the tool server. The host is the only component that touches both gaps, which is exactly why it is the component that bridges the two protocols.
This deep dive walks each boundary in turn, shows how the host stitches them together, traces a single user turn through both, and gives you the precise language to defend the layering when an interviewer pushes on whether the two are really separate. By the end you should be able to draw the picture, name what crosses each gap, and say why changing one side never forces a change on the other.
The inner boundary: LLM to host
Function calling is a convention that lives entirely between the model and the host runtime. The host injects a tool schema into the prompt, usually as JSON Schema naming the function, its arguments, and its return shape. When the model decides to use that tool, it emits a structured payload like { name: "search_docs", arguments: { query: "vector index" } } in its completion. The host parses that payload and acts on it. The model never executes anything; it only proposes a call. Execution is always the host's job.
The defining property here is that there is no network and no protocol in the wire sense. Nothing leaves the inference loop. Function calling is a serialization contract: how the model expresses intent and how the host reads it back. The model's training, plus optional constrained decoding, is what makes it reliably emit the agreed shape rather than free-form prose. Take away the host, and a function call is just text the model generated; it does nothing on its own.
The vendors differ only in detail. OpenAI calls it tools, Anthropic uses a tool-use block, Gemini has its own envelope, but all three sit at exactly this inner boundary. The argument schema, the parallel-call rules, and the field names vary, yet the shape of the contract is identical: schema in, structured call out. None of them say anything about where the tool's implementation lives, how the host reaches it, or how the host learned the tool existed. That silence is precisely the gap the outer boundary fills.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Concern | Function calling | MCP |
|---|---|---|
| Boundary spanned | LLM to host | Host to tool server |
| What crosses it | Structured call object in the completion | JSON-RPC request over stdio or HTTP |
| Defined by | Each model vendor | Open spec, vendor-neutral |
| Has a network hop | No, in-prompt convention | Yes, to a separate server process |
| Competing or stacked | Stacked, model-facing layer | Stacked, tool-facing layer |
Real products, models, and research that use this idea.
- Claude Code emits Anthropic-format function calls on the model side and reaches every registered server over MCP on the tool side.
- Cursor and Zed both adopted MCP in 2025, so a single filesystem server plugs into either host without touching the model-facing schema.
What an interviewer would ask next. Try answering before peeking at the approach.
QTrace one user turn through both boundaries end to end. Where does each protocol act?
Host discovers tools over MCP at startup, injects them as function schemas; model emits a call; host maps it back to the owning server and dispatches tools/call over JSON-RPC.
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.
Placing both at the same layer and calling them rivals. Function calling is LLM facing; MCP is tool facing. One app speaks both at once.
60 second bullets to scan on the way to the call.
Which boundary function calling spans
Which boundary MCP spans
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.