A language model that needs to check a live stock price cannot generate the number from training data. It emits a structured request naming a function and its arguments; an external system executes it and returns the result. That outward-facing mechanism is function calling. If the tool lived on a remote server the agent discovered at runtime (one no developer had hard-coded into the app), the layer that made discovery possible is MCP.
They are not two names for the same thing. One is a model capability; the other is a protocol.
Function calling: what the model outputs
Function calling is an LLM capability, not a transport standard. When the model decides a tool is needed, it does not run anything. It generates a structured output, typically JSON, specifying the function name and the arguments to pass:
{"function": "get_stock_price", "arguments": {"ticker": "AAPL"}}An orchestrating system intercepts that, runs the function, and injects the result back into the conversation. The model reads the result and continues.
For this to work, available functions must be declared before the model runs, usually as JSON Schema definitions in the system prompt or API call. The model selects from that declared set. Yao et al. formalised this interplay between reasoning and tool calls in the ReAct framework (ICLR 2023, arXiv:2210.03629), showing that interleaving reasoning with execution produces outputs less prone to hallucination than text generation alone.
Because each provider defines function calling independently, there is no shared wire format the model uses when it calls a tool. OpenAI uses a tools array and returns tool_calls; Anthropic uses input_schema. A system built against one does not work against the other without an adapter. Function calling is a behaviour; it carries no portability across model providers on its own.
MCP: how tools reach the model at scale
MCP (Model Context Protocol) is an open protocol based on JSON-RPC 2.0, open-sourced by Anthropic in November 2024 and now governed by the Linux Foundation. Where function calling defines how a model expresses intent to use a tool, MCP defines how tools are described and discoverable in the first place.
The key mechanism is runtime discovery. A host application sends a tools/list request to an MCP server and receives the available tools live, without a code change or advance documentation. It then calls one via tools/call. A server can also notify connected clients when its offerings change, so the set of available tools is not frozen at build time (MCP specification, version 2025-11-25, tools reference).
Without a shared protocol, connecting many applications to many tools requires a bespoke integration for each pair. MCP collapses that: each application speaks MCP once; each tool ships one MCP server once. The protocol’s broad adoption (OpenAI and Google DeepMind both adopted it after the initial Anthropic release) follows from that reduction in integration overhead rather than from any new capability.
How they compare
| Axis | Function calling | MCP |
|---|---|---|
| What it is | An LLM capability | An open protocol |
| Where it lives | Inside the model turn | Between host application and tool server |
| Who defines it | Each model provider independently | Open spec; Linux Foundation since December 2025 |
| Discovery | Functions declared ahead of time | Tools discovered at runtime via tools/list |
| Standard | Per-provider API shape | JSON-RPC 2.0 across all compliant participants |
| Scale | One integration per tool per application | Any application reaches any server through one standard |
The layer most comparisons skip
MCP does not sit beside function calling; it sits above it.
When a model calls an MCP tool, the mechanism is a function call. The MCP client exposes available MCP tools to the model as function definitions. The model issues a function call. The client translates that into a tools/call request to the remote server. Replace MCP with a hand-wired function: the model’s side of the transaction is identical. The only difference is where the tool definition came from and whether a developer or a runtime discovery step put it there.
MCP requires function calling to deliver its requests; function calling does not require MCP to work. The question of which to choose does not arise once you see that one occupies the model turn and the other occupies the layer between systems.
Sources: Model Context Protocol specification, version 2025-11-25, tools reference; Shunyu Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models (ICLR 2023).
Questions, answered
Can I use function calling without MCP?
Yes. Function calling works without MCP: declare available functions in the API call, the model emits a structured request, and your code runs it. MCP adds runtime tool discovery and a standard transport layer on top. It is useful at scale; it is not required for function calling to work.
Does MCP replace function calling?
No. MCP uses function calling as its mechanism. When a model calls an MCP tool, it issues a function call; the MCP client translates that call into a tools/call request to the remote server. MCP standardises the layer above the mechanism, not the mechanism itself.
Why does function calling look different in OpenAI versus Anthropic?
Function calling is defined per-provider, not by a shared standard. OpenAI uses a tools array and returns tool_calls in the response; Anthropic uses input_schema. The pattern is the same (model emits structured JSON, code executes it) but the interface shape differs because no standard governs the model-side API.
Is tool use the same as function calling?
They are used interchangeably today. 'Function calling' named the pattern when it first appeared. 'Tool use' became common as the same mechanism expanded to cover web search, code execution, and other action types. Both refer to the same underlying LLM capability.
Brief is a team of AI associates you direct in plain language. Opening to a small group at a time.
Request access