MCP and function calling are not competing standards, and the Reddit threads treating them as an either/or choice are missing the point entirely. Function calling is Phase 1: the LLM analyzes a request and outputs structured JSON describing which tool to invoke and with what arguments. MCP is Phase 2: the infrastructure layer that makes those tool calls portable, discoverable, and executable across any model or application. One is the brain deciding what to do. The other is the hands doing it.
The confusion is understandable. Both involve “calling tools.” Both produce JSON. Both connect LLMs to external systems. But they operate at different layers of the stack, and understanding that distinction is the difference between building an agent that works with one model and building one that works with any model.
Function Calling: How LLMs Express Intent
Function calling (also called “tool use”) is the mechanism by which an LLM outputs structured data instead of free text when it determines an external action is needed. You define tools as JSON schemas, send them alongside the user’s prompt, and the model returns a structured call with the function name and arguments. Your application code then executes the actual function and sends the result back to the model.
Here is how it works with OpenAI’s API:
tools = [{
"type": "function",
"function": {
"name": "get_weather",
"description": "Get current weather for a city",
"parameters": {
"type": "object",
"properties": {
"city": {"type": "string"}
},
"required": ["city"]
}
}
}]
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "Weather in Berlin?"}],
tools=tools
)
# Model returns: {"name": "get_weather", "arguments": {"city": "Berlin"}}
# Your code executes the actual API call
The critical detail: the model never executes anything. It generates a structured request. Your application parses that JSON, calls the real weather API, and feeds the result back. The LLM is a router, not an executor.
The Vendor Lock-in Problem
Every provider implements function calling differently. OpenAI uses a parameters key and returns tool_calls with serialized JSON strings. Anthropic uses input_schema and returns tool_use content blocks with inline objects. Google Gemini uses a flat structure with its own key names. Switching providers means rewriting your tool definitions, response parsing, error handling, and dispatch logic.
For a single-provider project, this does not matter. For anything that needs to survive a provider switch, or for teams running different models for different tasks, it becomes expensive fast.
MCP: The Execution Infrastructure Layer
The Model Context Protocol solves a different problem. Created by Anthropic in November 2024 and now governed by the Agentic AI Foundation under the Linux Foundation, MCP standardizes how AI applications discover, connect to, and invoke external tools and data sources.
MCP uses a client-server architecture with three components:
MCP Host: Your AI application (Claude Desktop, Cursor, a custom chatbot). The thing the user interacts with.
MCP Client: Middleware inside the host that manages connections to MCP servers. Each client maintains a 1:1 connection with a specific server and handles protocol negotiation.
MCP Server: A separate process that wraps an external system (GitHub, Postgres, Slack, a file system) and exposes it through a standardized interface using JSON-RPC 2.0.
Unlike function calling, MCP servers expose four capability types, not just tools:
- Tools: Callable actions with side effects (create a ticket, send a message)
- Resources: Structured read-only data access (fetch a file, read database records)
- Prompts: Reusable prompt templates for common interactions
- Sampling: Allows servers to request LLM completions through the client, enabling recursive agentic patterns
The ecosystem has grown to 97 million monthly SDK downloads across Python and TypeScript, with over 10,000 active public servers. OpenAI, Google, Microsoft, and AWS all support MCP natively in their platforms.
Seven Differences That Actually Matter
Developers on r/ClaudeAI and r/LocalLLaMA keep asking “should I use MCP or function calling?” That question reveals the core misunderstanding. Here is what actually differs:
1. Position in the pipeline. Function calling operates at the front end, converting natural language into structured tool intent. MCP sits at the back end, providing the infrastructure to execute those intents across systems. They are sequential phases, not alternatives.
2. Standardization. Function calling schemas are vendor-specific. Every provider has its own format. MCP enforces a single, vendor-neutral protocol. Define a tool once on an MCP server and it works with Claude, GPT-4o, Gemini, and any future model that speaks MCP.
3. Coupling. Function calling embeds tool definitions directly in your application code, tightly binding them to a single agent. MCP decouples tools onto separate server processes, making them reusable across agents, teams, and applications without code duplication.
4. Discovery. Function calling tools are statically defined in each API request. MCP supports dynamic discovery via tools/list and automatic notifications when capabilities change via tools/list_changed. An agent connecting to an MCP server does not need to know what tools exist in advance.
5. Security isolation. With function calling, all API credentials live in your main application process. MCP isolates credentials per server. Your Slack MCP server holds only Slack tokens. Your database server holds only database credentials. A breach in one does not expose the others.
6. Scalability. Adding a new tool via function calling means modifying the application that embeds it. Adding a new MCP server means deploying an independent process that any MCP client can connect to. The difference between O(N*M) and O(N+M) when you have N models and M tools.
7. Context cost. Function calling sends tool schemas per request, but you control exactly which tools are included. MCP servers can expose dozens of tools, and each connected server adds its full schema to the context window. Five MCP servers with 10 tools each can consume 30% of your context before the agent reasons about anything. This is MCP’s most criticized trade-off.
The Decision Framework: A Concrete Flowchart
Stop asking “MCP or function calling?” Start asking “what am I building?”
Use function calling when:
- You have 2-5 tools that are specific to your application’s logic (routing, validation, classification)
- You are prototyping and need something working in 20 lines of Python
- Latency matters more than portability (in-process execution, no network hop)
- Single provider with no plans to switch models
- Simple tasks: extracting structured data from text, categorizing support tickets, processing forms
A support ticket classifier that extracts customer name, issue type, and urgency from free text? Function calling. The tool definition is 15 lines, the execution is in-process, and you do not need it to work with any other model.
Use MCP when:
- 10+ tools across multiple external systems
- Multiple agents or applications need the same integrations (CRM, ticketing, databases)
- Cross-model compatibility matters (you run Claude for reasoning and GPT-4o for code generation)
- Credential isolation is a security requirement
- Multiple teams consume the same tool integrations
- Enterprise governance: you need audit trails, access control, and centralized tool management
A sales AI that needs Salesforce data, sends emails via SendGrid, logs activities in HubSpot, and queries an internal analytics database? MCP. You write each integration once as an MCP server. Every agent, regardless of model, connects through the same protocol. When the CRM team updates the Salesforce integration, every consuming agent gets the update automatically.
The Hybrid Pattern: How Production Systems Actually Work
Most production agent systems use both, and the split follows a clean architectural line.
Function calling handles agent-specific logic inside the conversation loop: routing decisions, validation gates, business rules, format conversion. These are fast, in-process operations that belong to the agent, not the infrastructure.
MCP handles shared integrations at the infrastructure layer: database access, third-party APIs, file operations, anything that multiple agents or applications need. These run as separate processes with their own credentials and lifecycle.
User request
→ LLM (function calling generates structured tool intent)
→ Application checks: local tool or MCP tool?
→ Local: execute in-process (fast, no network hop)
→ MCP: route to MCP client → MCP server → external service
→ Result returned to LLM for response generation
A concrete example: a customer service agent uses function calling for intent classification (is this a billing question, a technical issue, or a complaint?) and routing logic (escalate complaints to a human). It uses MCP for the actual work: querying the customer database, creating support tickets in Jira, and sending follow-up emails. The classification is agent-specific. The integrations are shared across every agent in the organization.
Watch the Token Budget
One production consideration that does not get enough attention: MCP’s context cost. Each connected MCP server sends its full tool schema to the LLM. A Jira MCP server with 15 tool definitions can consume 2,000-3,000 tokens before the agent processes a single user message. Connect five servers and you have lost 30% of a 128K context window to tool descriptions alone.
The fix is selective connection. Do not connect every MCP server to every agent. Connect only the servers that agent actually needs. Some teams use a lightweight routing layer that connects MCP servers dynamically based on the user’s request, rather than loading everything upfront.
Security: The Part Nobody Talks About First
MCP’s credential isolation is a genuine architectural advantage over function calling, but the protocol has its own security surface. In the first 60 days of 2026, over 30 CVEs were disclosed in the MCP ecosystem. CVE-2025-6514 in the mcp-remote package affected 437,000+ environments with a CVSS score of 9.6. A study found that 43% of sampled MCP servers contained command injection vulnerabilities.
Function calling’s security model is simpler: your application holds all credentials and executes all tools. The attack surface is your application. With MCP, the attack surface expands to every connected server, the transport layer between them, and the tool descriptions themselves (which can be poisoned to manipulate LLM behavior).
Neither approach is inherently more secure. Function calling concentrates risk. MCP distributes it. The right choice depends on whether you prefer a single fortified perimeter or defense in depth with more gates to audit.
Frequently Asked Questions
Does MCP replace function calling?
No. MCP and function calling operate at different layers. Function calling is how an LLM generates structured tool intent (Phase 1). MCP is the infrastructure that executes those intents portably across models and applications (Phase 2). Most production systems use both together.
When should I use function calling instead of MCP?
Use function calling for 2-5 agent-specific tools, rapid prototyping, latency-sensitive operations, single-provider deployments, and simple tasks like data extraction or classification. Function calling is faster (in-process, no network hop) and simpler to implement for small-scale use cases.
When should I use MCP instead of function calling?
Use MCP when you have 10+ tools across external systems, need cross-model compatibility, require credential isolation for security, have multiple agents sharing the same integrations, or need enterprise governance features like audit trails and access control.
Which AI providers support MCP in 2026?
As of March 2026, MCP is supported by Anthropic (creator), OpenAI (since March 2025), Google DeepMind (since April 2025), Microsoft, AWS, Cloudflare, and Bloomberg. The protocol is governed by the Agentic AI Foundation under the Linux Foundation and has over 97 million monthly SDK downloads.
Can I use MCP and function calling together?
Yes, and most production systems do. The typical pattern uses function calling for agent-specific logic (routing, validation, classification) executed in-process, and MCP for shared infrastructure integrations (databases, APIs, file systems) that run as separate server processes. Function calling handles the brain; MCP handles the hands.