MCP vs function calling: what's actually different

The debate around mcp vs function calling often conflates a wire protocol with a model feature. They solve adjacent problems: function calling is how a model emits structured intents to invoke code you defined inline, while MCP is a standardized transport for exposing tools, resources, and prompts to a model across process boundaries. Treating them as competitors misses the point—but you still need to choose where to invest.

What each actually is

Function calling

Function calling (also called tool calling) is a native model capability. You send a JSON schema describing functions in the request, the model returns a tool_calls block with arguments, and you execute the function locally. It is synchronous with the inference call and exists entirely within the chat completions API surface.

Every major provider supports some variant: OpenAI, Anthropic, Gemini, Mistral. The schemas differ slightly but the pattern is identical.

MCP

The Model Context Protocol is an open JSON-RPC based protocol introduced by Anthropic in late 2024. It defines a client-server relationship where an MCP server exposes tools, resources, and prompts over a transport (stdio or SSE). The model host runs an MCP client that discovers capabilities and forwards tool calls.

MCP is not a model feature. A model still emits a tool call; the MCP layer decides where that call executes and how the result returns.

Head-to-head dimensions

Capabilities

Function calling gives you exactly one primitive: invoke a named function with typed arguments. You manage discovery, authentication, and execution yourself.

MCP gives you three primitives: tools (executable), resources (read-only context like files or DB rows), and prompts (templated interactions). It also specifies lifecycle events, bidirectional streaming, and standardized error codes. If you need to stream a large dataset into context without stuffing the chat history, MCP resources win.

In the mcp vs function calling comparison, capabilities are not overlapping—MCP wraps function calling and adds context plumbing.

Cost model

Neither protocol charges a fee. The cost difference is operational. Function calling inflates your input tokens: every tool schema rides along in the context window on each request unless you prune. MCP lets a client cache tool definitions server-side and fetch them on startup, but you pay to run the MCP server (process, auth, network).

If you front model traffic with an inference gateway such as n4n.ai, its automatic fallback when a provider is rate-limited or degraded sits above whichever tool mechanism you pick—the gateway speaks OpenAI-compatible chat completions and forwards your tool schemas unchanged.

Latency and throughput

Function calling is a single HTTP round trip to the model plus your local execution. MCP adds at least one RPC hop to a separate server, plus connection setup (especially over SSE). For a tool that runs in 10ms locally, MCP overhead can double end-to-end latency.

Throughput suffers similarly: each tool call serializes through the MCP client. But MCP shines when a tool fetches a 50MB log file as a resource—function calling would blow the context window and your token bill.

Ergonomics

Function calling is trivial. You write a dict, call the API, parse tool_calls. Debugging is print-statements and curl.

MCP requires standing up a server, managing its lifecycle, and using a client library. The Python SDK is maturing but still demands boilerplate. For a solo script, MCP is overkill.

Ecosystem and tooling

Function calling is universally supported. You can swap models behind an OpenAI-compatible endpoint and keep the same tool definitions.

MCP has a growing registry of prebuilt servers (GitHub, Postgres, Slack) but adoption is early. You will write custom servers for internal systems. The payoff is composability: one MCP server can serve multiple agent hosts.

Limits

Function calling limits: context window size for schemas, model’s maximum tool count (often 64–128), and no standardized way to attach external data without polluting chat.

MCP limits: few production-grade client implementations outside Anthropic’s reference, auth is DIY, and streaming over stdio is awkward in serverless. The protocol is young; specs shift.

Comparison table

Same tool, two ways

A weather lookup under function calling:

from openai import OpenAI
client = OpenAI()

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role":"user","content":"Weather in NYC?"}],
    tools=[{
        "type":"function",
        "function":{
            "name":"get_weather",
            "description":"Current weather for a city",
            "parameters":{
                "type":"object",
                "properties":{"city":{"type":"string"}},
                "required":["city"]
            }
        }
    }]
)
print(resp.choices[0].message.tool_calls)

The same tool exposed via MCP tools/list:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Current weather for a city",
        "inputSchema": {
          "type": "object",
          "properties": {"city": {"type": "string"}},
          "required": ["city"]
        }
      }
    ]
  }
}

And the call:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {"name": "get_weather", "arguments": {"city": "NYC"}}
}

The model output format is analogous; the difference is where the schema lives and who executes the result.

Which to choose

Use function calling if

• You build a single agent in one codebase.
• Your tools number under a few dozen and fit in context.
• You want zero infra beyond your app process.
• You need to switch model providers without rewriting tool layers.

This is the default for 80% of shipping LLM features.

Use MCP if

• Multiple agent hosts (Claude Desktop, custom bots) should share the same backend tools.
• You must pipe large external data (logs, repos) into context without tokenizing everything into chat.
• You want standardized discovery so new capabilities appear without client code changes.
• You can afford to operate a long-lived server.

Hybrid

Run MCP servers for heavy integrations, but map their tools into function-calling schemas at the gateway. The model never sees MCP; your client translates. This gets you shared infra without forcing every experiment through the protocol.

The mcp vs function calling decision is ultimately about topology. Function calling is a feature; MCP is a system. Pick the feature until the system earns its keep.