Explain the architectural difference between MCP and vendor function calling. At which layer does each operate, and describe a system where you would use both simultaneously.
Free · 2 AI evals / day
There are three players in an agentic system: the LLM, the host application, and the external tool. The two mechanisms each sit between a different pair.
**Function calling** is the LLM-to-host contract. The model outputs a structured object, 'call `read_file` with `path=main.py`', and the host parses it. This is the model expressing intent in a shape the host can read.
**MCP**, the Model Context Protocol, is the host to tool contract. Once the host knows the model wants `read_file`, it uses MCP to actually invoke that tool on an external server over a standard wire protocol.
So they are not competitors. Function calling answers 'how does the model say what it wants?' MCP answers 'how does the host reach the real tool?' A normal agent uses both in one turn: the model signals intent via function calling, then the host fulfills it via MCP. Neither layer knows the other exists, which is exactly why they compose so cleanly.
They occupy different boundaries of the same agent stack, so they compose rather than compete.
**Function calling** is the LLM-to-host layer. The model emits a typed payload like `{ name: "read_file", arguments: {...} }`. The host intercepts it. OpenAI, Anthropic, and Gemini each ship a variant. It is purely a format for the model to express intent.
**MCP** is the host to server layer. It defines the wire protocol, JSON-RPC over stdio or streamable HTTP, that the host uses to discover and invoke capabilities on external servers. A server advertises tools, resources, and prompts. The host pulls that catalog at startup.
The two stack vertically. Picture a coding agent connected to a filesystem MCP server. At startup the host runs discovery and learns the server offers `read_file`. It registers that as a function-callable tool for the model. The model emits a function call. The host translates it into an MCP `tools/call`, executes it, and feeds the result back. The model never sees MCP. The server never sees the function-call schema. The host bridges the two, which is why you run both at once.
Quick reference
TL;DR
Function calling is the LLM-to-host intent layer; MCP is the host to server integration layer. They stack, so a real agent uses both at once.
Picture ordering at a restaurant. Function calling is you telling the waiter, in a clear set phrase, exactly what you want: 'one pasta, no cheese.' The waiter understands the format and writes it down. MCP is the standardized system behind the kitchen door that lets the waiter pass that order to any station, the grill, the salad bar, the dessert counter, without the waiter needing to know how each one works inside. The waiter is the host application in the middle. You speak one clear language to the waiter, and the waiter speaks one standard protocol to the kitchen. Change the kitchen and the way you talk to the waiter never changes. Two different conversations, two different layers, and both are needed to actually get fed.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Single-vendor closed app with a handful of hard-coded tools MCP's payoff is cross-host reuse and dynamic discovery; with fixed tools and one model, the protocol and process boundary add latency for nothing.
Ultra-low-latency in-process tools with a sub-5ms budget JSON-RPC over stdio costs a few milliseconds per call, so a direct in-host function dispatch avoids the extra hop.
Long-lived streaming bidirectional tool sessions MCP is request-response with optional notifications, so persistent stateful streaming is awkward and usually belongs in a custom transport.
Quick scan · 2–4 min
Everything important, quickly.
5 min: name the three players, place each mechanism at its boundary, trace one turn through the host bridge, then give a Claude Code plus filesystem server example and a skip-MCP case.
Side-by-side
Concern
Function calling
MCP
Boundary
LLM to host
Host to external server
Job
Model expresses tool intent
Host discovers and invokes the tool
Defined by
Each model vendor
Open spec, vendor-neutral
Transport
Inside the prompt and completion
JSON-RPC over stdio or streamable HTTP
Primitives
Tool schemas and tool calls
Tools, resources, prompts
Reusable across apps
No, model-specific shape
Yes, one server runs in any host
Real-world examples
Real products, models, and research that use this idea.
1Claude Code registers tools from each configured MCP server at session start, then exposes them to Claude Opus 4.7 as native tool_use entries.
2Cursor and Zed both speak MCP, so a single filesystem or Postgres server written once runs unchanged across all three hosts.
3Anthropic's reference servers (filesystem, GitHub, Postgres, Slack) are discovered via MCP and surfaced to the model through vendor function calling.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWalk through one agent turn end to end: where exactly does the function call become an MCP invocation?
Sign in or go Pro to see the approach for this follow-up.
QIf MCP is vendor-neutral and function calling is vendor-specific, where does portability actually break?
Sign in or go Pro to see the approach for this follow-up.
QWhen would you skip MCP and wire tools directly through function calling?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Calling MCP a replacement for function calling. They sit at different boundaries, so the host runs both in the same request.