In Brief
Tool calling and MCP address the same surface need — connecting an LLM to external tools — but at two radically different levels of abstraction. Tool calling is an API primitive: it lives in the request payload, requires no infrastructure, and disappears with the conversation. MCP is a full network protocol: it requires a dedicated server, persistent connections, and in return opens capabilities that pure tool calling cannot offer. Choosing between the two is not a question of trend — it’s a question of architecture.
What Each Approach Solves
Tool Calling — The Direct Primitive
Tool calling (“tool use” at Anthropic, “function calling” at OpenAI) is integrated directly into the messages API. The application sends a list of tool definitions in JSON Schema format in the request payload. The model decides when to invoke them, emits a tool_use block, the application executes locally, returns a tool_result, and the cycle repeats.
All state is in the conversation. There is nothing to deploy, nothing to maintain. Anthropic’s documentation describes it as “one of the highest-leverage primitives you can give an agent”. The strict: true option guarantees schema conformance in production.
This model is stateless at the protocol level: each request is self-contained. The list of tools is fixed at call time. Discovery is impossible at runtime.
MCP — The Standardization Protocol
MCP (Model Context Protocol) is an open standard published by Anthropic in November 2024, whose current specification is versioned 2025-11-25. The spec’s analogy is USB-C: a universal connector for linking heterogeneous systems to AI clients. The declared inspiration is Microsoft’s Language Server Protocol (LSP).
The architecture has three distinct roles:
- MCP Host: the AI application (Claude Desktop, VS Code, Cursor…)
- MCP Client: internal component of the Host, maintains a dedicated connection per server
- MCP Server: program exposing capabilities via JSON-RPC 2.0
Two transports are available: stdio (the Host launches the server as a subprocess, communication via stdin/stdout, zero latency, local use) and Streamable HTTP (HTTP POST + optional Server-Sent Events, for remote access).
MCP is a stateful protocol: it manages a connection lifecycle, negotiates capabilities at handshake, and can send push notifications (notifications/tools/list_changed) when the list of tools changes during a session.
In short: tool calling lives in the conversation and dies with it. MCP lives in a dedicated server and outlives conversations. The infrastructure difference is not trivial — an MCP server is something you deploy, secure, monitor. Tool calling is just JSON in the request.
Comparison Table
| Dimension | Tool Calling | MCP |
|---|---|---|
| Abstraction level | API primitive (in the request) | Network protocol (separate layer) |
| Required infrastructure | None | Dedicated MCP server |
| Stateful | No (conversation) | Yes (persistent connections, sessions) |
| Exposed primitives | Tools only | Tools + Resources + Prompts + Sampling |
| Interoperability | Provider-specific | Cross-provider (Claude, ChatGPT, VS Code…) |
| Transport | N/A (inline API) | stdio (local) or Streamable HTTP (remote) |
| Tool discovery | List fixed in payload | Dynamic tools/list at runtime |
| Push notifications | No | Yes (notifications/tools/list_changed) |
| Problem solved | Ad hoc function call | M×N integrations → M+N |
The Three MCP Primitives With No Tool Calling Equivalent
Tool calling knows only one concept: the executable tool. MCP distinguishes three, with different control models:
| Primitive | Control | Tool calling equivalent | Description |
|---|---|---|---|
| Tools | Model | Yes | Executable functions, actions on the world |
| Resources | Application | No | Read-only data sources with unique URI (file:///path, calendar://events/…) |
| Prompts | User | No | Parameterized templates, reusable workflows (slash commands, palettes) |
The Sampling primitive goes in the other direction: the MCP server can request an LLM completion from the client. This is a reverse pattern with no equivalent in tool calling, with architectural implications not yet stabilized in the literature.
The M×N Problem
MCP’s primary justification is economic at the architecture level. Without a standard, M applications consuming N external systems generate M×N custom integrations to maintain. MCP transforms this problem into M+N: each system exposes an MCP server once, each AI client supports the protocol once.
For an isolated application calling two internal APIs, this argument doesn’t apply. For a team deploying multiple agents consuming the same systems (database, Slack, GitHub, Postgres), MCP eliminates integration code duplication. Official reference servers cover filesystem, GitHub, Slack, Postgres, Google Drive, SQLite, and Puppeteer.
Security: What MCP Formalizes That Tool Calling Does Not
The MCP spec 2025-11-25 introduces mechanisms absent from pure tool calling:
- Annotations on tools (behavioral metadata) — the spec states that clients must treat them as untrusted unless they come from a trusted server
- outputSchema: structured result validation on the client side
- Two distinct error types: Protocol Errors (JSON-RPC) vs Tool Execution Errors (
isError: true), allowing the model to self-correct on execution errors - Consent principles: explicit consent required before invocation, input validation, rate limiting, output sanitization — at SHOULD level (recommendation), not MUST (obligation)
The Streamable HTTP transport introduces a specific risk: DNS rebinding attacks. The spec requires that the server validate the Origin header and reject with HTTP 403 if invalid. Local servers must bind only on localhost.
In short: MCP formalizes concepts that tool calling leaves up to each application — return schema, distinct error types, consent recommendations. For a single agent, these formalisms are sugar. For a fleet of 50 agents shared in an enterprise, they become vital.
When to Use Each
Tool calling is the default choice when:
- The scope is limited (a few tools, a single application)
- Infrastructure must remain minimal (prototyping, occasional use)
- Tools don’t change during a session
- No sharing between applications is planned
MCP becomes relevant when:
- Multiple applications or agents consume the same systems
- Tools must be discovered dynamically at runtime
- The Resources or Prompts primitives are needed (read-only data exposed with URI, user templates)
- Team standardization is required (single reusable server)
- Multi-agent orchestration must rely on a composable ecosystem
Simon Willison noted in November 2024 that MCP configuration was “clunky” in its early versions (manual JSON editing, availability limited to Claude Desktop). The infrastructure complexity is real: lifecycle handshake, capability negotiation, persistent state management. This cost is justified when the composability and reusability gain outweighs this overhead.
The two approaches are not mutually exclusive: an agent can use tool calling for statically defined local tools and rely on MCP to access shared servers.
MCP Support in the Ecosystem
Anthropic created and maintains the protocol (Claude Desktop, Claude Code). MCP support is documented at OpenAI for ChatGPT [NOT VERIFIED — page inaccessible during collection]. Microsoft integrated it into Visual Studio Code with GitHub Copilot. Cursor, Windsurf, Replit, Codeium, Sourcegraph, and Zed have announced support on their development platforms.
Governance is open-source with a SEP (Specification Enhancement Proposals) process, documented at modelcontextprotocol.io.
Key Takeaways
Tool calling and MCP are not in direct competition: they operate at different levels. Tool calling is sufficient and optimal for the vast majority of application use cases — one API, one agent, a few tools. MCP brings real value as soon as the architecture involves multiple applications consuming the same systems, or when dynamic discovery and tool composability become constraints. The Resources and Prompts primitives, with no tool calling equivalent, open model-context interface possibilities that pure tool calling cannot cover. The decision is architectural, not trend-driven.