Vendor function calling operates at the LLM↔host boundary: the LLM decides to invoke a function and emits a structured call object; the host intercepts it. MCP operates at the host↔tool boundary: it defines the wire protocol the host uses to invoke capabilities on external servers. They are complementary, not competing: a typical agentic app uses both simultaneously.
Picture three boxes in a row: the **LLM**, the host app in the middle, and an external tool on the right. The whole question is which gap each protocol covers.
Function calling covers the left gap, between the LLM and the host. The model decides it wants a tool and emits a structured call object like `{ name: "search", arguments: {...} }`. The host catches that object. This is purely a format the model and host agree on.
MCP covers the right gap, between the host and the external tool server. Once the host knows the model wants a tool, MCP is the wire protocol it uses to actually reach a remote server, discover what that server offers, and invoke it over JSON-RPC.
So they sit at different boundaries. A real agent app speaks both at the same time: function calling on the model side, MCP on the tool side. Asking which one to choose is the wrong question, because each one owns a gap the other does not touch.
They sit at two different boundaries of the same agent stack.
**Function calling** lives at the LLM-to-host boundary. The model emits a structured call object, something like `{ name: "search", arguments: { q: "..." } }`, and the host intercepts it. The schema is injected into the prompt as a tool definition. The model is trained to honor that shape. OpenAI, Anthropic, and Gemini each ship a variant. It is the language the model uses to express intent.
MCP lives one boundary out, at the host to tool boundary. It is a JSON-RPC protocol the host speaks to external servers. The host connects, discovers what tools, resources, and prompts a server offers, then invokes them. Think of it as the standard port the host plugs capability providers into.
The two compose cleanly. The host discovers a tool over MCP, then registers it with the model using the vendor's function-calling format. They are complementary, never competing. A typical 2026 agentic app runs both at once: function calling on the model side, MCP on the tool side. Using one does not stop you using the other.
Quick reference
TL;DR
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.
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.
A closed single-vendor app with a few hard-coded tools and no plug-in story MCP's value is cross-host reuse; without it you pay protocol and discovery overhead for nothing.
Ultra-low-latency in-process tools with a budget under five milliseconds The JSON-RPC hop on the host to tool boundary costs a few milliseconds a direct in-process dispatch avoids.
A model with no native function-calling support behind your host The inner boundary has no structured-call convention, so you fall back to prompt parsing before MCP even matters.
Quick scan · 2–4 min
Everything important, quickly.
4 min: name the two boundaries, place each protocol, trace one turn through both, then explain why swapping either side leaves the other untouched.
Side-by-side
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-world examples
Real products, models, and research that use this idea.
1Claude Code emits Anthropic-format function calls on the model side and reaches every registered server over MCP on the tool side.
2Cursor and Zed both adopted MCP in 2025, so a single filesystem server plugs into either host without touching the model-facing schema.
3OpenAI's tools API and Gemini function calling occupy the same inner boundary that an MCP-aware host wires its discovered tools into.
Interviewer follow-ups
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?
Sign in or go Pro to see the approach for this follow-up.
QIf you swap the model vendor from one provider to another, what changes at each layer?
Sign in or go Pro to see the approach for this follow-up.
QWhy can the host expose the same MCP tool to the model under a different name or schema?
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
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.