MCP vs Function Calling: What Developers Need to Know

MCP vs Function Calling: What Developers Need to Know

Photo by DeepMind on Unsplash

Quick Answer: They're not competitors — they're different layers. Function calling is a model API feature: you pass a tools array with JSON schemas, the model returns structured calls, your code executes them. MCP (Model Context Protocol) is an open protocol that standardizes where those tools come from: reusable tool servers that any MCP host (Claude, ChatGPT, Cursor, VS Code, your own agent) can discover and use. Under the hood, MCP hosts translate MCP tools into function calls. Building one app with 3 tools? Plain function calling is simpler. Sharing tools across multiple apps, agents, or desktop hosts? MCP wins — and in 2026 it's the de facto standard, with every major model provider and IDE shipping native support.

On This Page

• What Function Calling Actually Is
• What MCP Actually Is
• The N×M Integration Problem
• Architecture Comparison
• When Plain Function Calling Is Simpler
• When MCP Wins
• Code-Level Contrast
• How They Compose
• Adoption Landscape in 2026
• Frequently Asked Questions

What Function Calling Actually Is

Function calling (also called "tool use") is a feature of a model provider's API. You send the model a list of tool definitions — name, description, JSON Schema parameters — alongside the conversation. The model doesn't execute anything; it returns a structured message saying "call get_weather with {"city": "Austin"}". Your application code executes the function, appends the result to the conversation, and calls the model again.

Every major API supports it with minor dialect differences: OpenAI's tools array, Anthropic's tools with input_schema, Gemini's function declarations. The loop is always the same:

1. Send messages + tool schemas
2. Model responds with tool call(s)
3. Your code runs the function
4. Send the result back
5. Model produces the final answer (or more tool calls)

The critical property: the tools live inside your application. They're defined in your codebase, executed by your process, invisible to any other app.

What MCP Actually Is

The Model Context Protocol, open-sourced by Anthropic in November 2024 and governed openly since, is a client-server protocol — JSON-RPC 2.0 over stdio or Streamable HTTP — that standardizes how AI applications connect to external capabilities. Think "USB-C for AI tools," or more precisely, what the Language Server Protocol did for editor-language integrations.

An MCP server is a small program exposing three primitive types:

• Tools — executable functions (query a database, create a ticket, run a search)
• Resources — readable data (files, schemas, documents) the host can load as context
• Prompts — reusable prompt templates the user can invoke

An MCP host (Claude Desktop, Claude Code, ChatGPT, Cursor, VS Code Copilot, or your own agent built on any framework) connects a client to each configured server, calls tools/list to discover what's available at runtime, and invokes tools with tools/call. The server doesn't know or care which host is calling it, or which model that host is running.

The key property is the mirror image of function calling: the tools live outside any single application, behind a standard interface any host can consume.

The N×M Integration Problem

Why does a protocol matter at all? Because of integration math.

Say your company has 4 AI surfaces — a customer-facing chatbot, an internal Slack agent, Claude Desktop for the ops team, Cursor for engineering — and 6 systems they should all reach: Postgres, GitHub, Jira, Salesforce, an internal wiki, and a billing API.

With app-local function calling, that's 4 × 6 = 24 bespoke integrations, each with its own schema definitions, auth handling, error mapping, and bit-rot. Every new AI app re-implements the same six connectors; every API change breaks four codebases.

With MCP, you build 6 servers, once. Each of the 4 hosts connects to all of them through the same protocol: N + M instead of N × M. The Jira server your platform team hardened — auth, rate limits, input validation — is the same one your chatbot, your Slack agent, and every engineer's IDE use.

"MCP did to agent tooling what LSP did to language tooling: it turned an O(N×M) mess into an O(N+M) ecosystem, and the long tail of integrations appeared almost overnight." — The Pragmatic Engineer, Q1 2026

Architecture Comparison

Photo by AltumCode on Unsplash

When Plain Function Calling Is Simpler

MCP is not a default. Plain function calling is the right call when:

• Single application, few tools. One backend service with 3-8 tools that nothing else will ever use? A protocol layer adds a server process, transport, and lifecycle management for zero payoff.
• Latency-critical paths. In-process function dispatch has no IPC or HTTP hop. For high-QPS production inference where every millisecond counts, local tools win.
• Tight coupling is a feature. When tools need your app's internal state — the user's session, an open DB transaction, request-scoped permissions — passing that context through a protocol boundary is awkward. In-process tools just close over it.
• You control the whole stack and it's small. A weekend project or a single-purpose product does not need ecosystem interoperability.

Rule of thumb: if the tool has exactly one consumer, keep it a function. Extract it to an MCP server the day a second consumer shows up — the refactor is mechanical because the JSON Schema shapes are nearly identical.

When MCP Wins

• Shared tool servers. The moment two or more AI surfaces need the same capability, MCP's N+M math takes over.
• Desktop and IDE hosts you don't control. You cannot add a tools array to Claude Desktop, ChatGPT, or Cursor — but all of them load MCP servers. If you want your tool inside their host, MCP is the only door.
• Ecosystem distribution. Publishing one server puts your product in reach of every MCP host user. That's why Stripe, GitHub, Cloudflare, Notion, Supabase, and thousands of others ship official servers.
• Org-level governance. Central platform teams can harden one server — auth, audit logging, rate limits — instead of policing tool code scattered across every team's agents. See the OWASP guidance on LLM tool security for why centralizing this matters.
• Dynamic toolsets. MCP hosts discover tools at runtime, so a server can expose different tools per user, plan tier, or environment without redeploying any host.

The decision, condensed:

Code-Level Contrast

Function calling — the tool is an in-process array entry (OpenAI-style):

tools = [{
    "type": "function",
    "function": {
        "name": "get_invoice",
        "description": "Fetch an invoice by ID",
        "parameters": {
            "type": "object",
            "properties": {"invoice_id": {"type": "string"}},
            "required": ["invoice_id"],
        },
    },
}]

resp = client.chat.completions.create(model="gpt-5.2", messages=msgs, tools=tools)
call = resp.choices[0].message.tool_calls[0]
result = get_invoice(**json.loads(call.function.arguments))  # you execute

MCP — the same tool as a standalone server any host can load (Python SDK):

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("billing")

@mcp.tool()
def get_invoice(invoice_id: str) -> dict:
    """Fetch an invoice by ID."""
    return db.fetch_invoice(invoice_id)

if __name__ == "__main__":
    mcp.run()  # stdio transport; hosts connect via config

A host config entry (Claude Desktop / Claude Code style) is all a consumer needs:

{ "mcpServers": { "billing": { "command": "python", "args": ["billing_server.py"] } } }

Notice what didn't change: the JSON Schema for parameters, the description, the function body. What changed is who can call it — everything, instead of one app.

How They Compose

The most misunderstood point: MCP doesn't replace function calling — it feeds it. Models don't speak MCP. The host does the translation:

1. Host connects to configured MCP servers, calls tools/list
2. Host converts each MCP tool definition into its model's native function-calling schema
3. Model emits an ordinary tool call
4. Host routes it back through tools/call on the right server
5. Result returns to the model as a normal tool result

So the accurate mental model is a pipeline: MCP standardizes tool supply; function calling is how the model consumes them. This is also why "MCP vs function calling benchmarks" are mostly nonsense — every MCP tool invocation is a function call plus transport overhead (typically single-digit milliseconds on stdio, one HTTP round-trip for remote servers).

One real cost to watch: context bloat. Every connected server's tool schemas land in the model's context. Hosts in 2026 mitigate this with tool filtering, lazy loading, and search-over-tools, but connecting 15 servers with 200 combined tools will still degrade tool-selection accuracy. Curate ruthlessly — our agent context engineering guide covers this in depth.

Adoption Landscape in 2026

The practical upshot for developers in 2026: function calling is table stakes knowledge for any LLM feature, and MCP is table stakes for anything meant to plug into the broader agent ecosystem. Learn the loop first, the protocol second — and remember they're the same tools wearing different transport layers.

Related Reads

• How to Build an MCP Server: Complete 2026 Tutorial

Key Takeaways

• Function calling is an API feature where you define tools in your app’s code (JSON schemas) and the model returns structured calls for your app to execute—ideal for single-app, low-latency, or tightly coupled use cases.
• MCP (Model Context Protocol) is an open JSON-RPC 2.0 protocol that standardizes tool discovery via external servers, enabling N+M integrations (one server for many hosts) instead of N×M bespoke integrations—critical for shared tools, desktop/IDE hosts, or ecosystem distribution.
• Use plain function calling when building a single app with 3–8 tools, latency-sensitive paths, or tools that need app-internal state (e.g., sessions, DB transactions); refactor to MCP only when a second consumer emerges.
• MCP wins for shared tool servers, desktop/IDE hosts (Claude, Cursor, VS Code), org-wide governance (centralized auth/auditing), or dynamic toolsets (per-user/per-tier)—publish one server to reach every MCP-compatible host.
• MCP and function calling compose: hosts translate MCP tool definitions into the model’s native function-calling schema at runtime, so MCP standardizes tool supply while function calling handles model consumption—benchmarks comparing them directly are misleading.
• In 2026, MCP is the de facto standard for cross-app tooling, with native support in every major model provider and IDE; learn function calling first for core LLM features, then MCP for ecosystem interoperability.