Different layers, both needed. Function calling is the LLM-side mechanism: a structured way for the model to say 'call this tool with these args'. MCP is the wire protocol on the OUTSIDE, it defines how the host application discovers and invokes tools (or fetches resources, or pulls prompts) on remote servers. You can use MCP under the hood and still expose function-calling semantics to the LLM.
**Function calling** is what the LLM does. The model outputs a structured object that says 'I want to call `get_weather` with `city=Paris`'. The host application parses that, runs the function, and feeds the result back.
**MCP** (Model Context Protocol) is what the host does. It's a JSON-RPC protocol that lets the host connect to an external MCP server and ask, 'what tools, files, and prompts do you offer?' The server replies with a catalog. The host then exposes those tools to the LLM via the function-calling format the model understands.
The two layers are complementary. Function calling solves 'how does the model express intent'. MCP solves 'how does the host find and connect to the tools in the first place'. A modern stack uses both: MCP for discovery and transport, function calling as the model-facing surface.
Different layers of the same agent stack, not competitors.
**Function calling** is the model-side contract. The LLM emits a JSON object like `{ name: "search", arguments: { q: "..." } }` and the host runs it. OpenAI, Anthropic, and Gemini all support some variant. It's the language the model speaks to express a tool call.
**MCP** is the host to server protocol that sits one layer below. An MCP server advertises tools, resources (files, data), and prompt templates over JSON-RPC. The host connects to one or more servers, pulls the catalog, and registers those entries as function-callable tools for the LLM. Think USB-C for context: any compliant server plugs into any compliant host without custom glue.
The practical win is **decoupling**. Before MCP, every app shipped bespoke integrations per vendor. With MCP, a single filesystem server, GitHub server, or Postgres server works in Claude Code, Cursor, Zed, or any compliant host. You can use both simultaneously, MCP underneath, function calling on top.
Quick reference
TL;DR
Function calling is the LLM's tool-call vocabulary; MCP is the host to server protocol that delivers tools, resources, and prompts to the LLM in the first place.
Imagine a TV remote and the HDMI cable behind your TV. The remote (function calling) is how you tell the TV which input to switch to. The HDMI cable (MCP) is the standard wire that lets any device, a Blu-ray, a console, a streaming stick, plug into the TV without redesigning the back panel. Function calling is the model saying 'play movie' in a structured shape the host knows how to read. MCP is the standardized port behind the host that lets it talk to any tool server, file server, or prompt server without writing a custom integration per vendor. They live at different layers and play well together.
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, single-app stack with no plug-in story MCP's value is cross-host reuse; if you ship a closed app calling one vendor's tools, the protocol overhead adds startup latency without payoff.
Ultra-low-latency in-process tools (<5ms budget) JSON-RPC over stdio costs a few milliseconds per call; a direct function dispatch inside the host avoids that hop.
Tools that need streaming bidirectional state MCP is request-response with optional notifications; long-lived stateful sessions are awkward and usually belong in a custom transport.
Quick scan · 2–4 min
Everything important, quickly.
4 min: two-layer stack + three MCP primitives + JSON-RPC transport + discovery flow + when to skip MCP and hand-roll.
Side-by-side
Concern
Function calling
MCP
Layer
Model output contract
Host-to-server protocol
Defined by
Each model vendor (OpenAI, Anthropic, etc.)
Open spec, vendor-neutral
Transport
Inside the prompt and completion
JSON-RPC over stdio or HTTP+SSE
Primitives
Tool schemas, 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 ships a built-in MCP client and discovers tools from any registered server at session start.
2Anthropic's MCP server registry exposes filesystem, GitHub, Postgres, and Slack servers as drop-in plug-ins.
3Cursor and Zed both adopted MCP in 2025 so any MCP server written for Claude Code works in them too.
Interviewer follow-ups
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?
Sign in or go Pro to see the approach for this follow-up.
QWhen would you NOT use MCP and prefer direct function calling?
Sign in or go Pro to see the approach for this follow-up.
QHow do resources differ from tools, and when does that matter?
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
Treating MCP and function calling as competing standards. They sit at different layers, the host can speak both at once.