Function Calling vs MCP: What Changed for Tool Use in 2026

Function calling vs MCP comes down to where the tool lives: function calling defines a tool inside one app's API request and your own code runs it, while MCP puts the tool on a server that any MCP client can discover and call. The model does the same thing in both cases, which is to return a tool name and JSON arguments, so the choice is about ownership and reuse, not capability.

Checked October 2026 against Anthropic's tool use, MCP connector and tool search docs, OpenAI's function calling and MCP servers guides, Google's Gemini function calling page, and the MCP specification (tools, authorization, 2026-07-28 changelog).

This comparison is built from those documents, not from our own benchmarks: every token figure below is a number Anthropic or OpenAI publishes, and the cost lines are labelled arithmetic. For what input tokens cost per model, keep our LLM API pricing comparison open in another tab. If MCP itself is new to you, read what the Model Context Protocol is first.

Function calling vs MCP: the short answer

Use function calling when one app owns the tool. Use MCP when more than one client needs it. Use both when your product has private logic and shared systems, which describes most products once they are past the prototype.

• Pick function calling if the tool touches your own database or internal state, only your app will ever call it, and you want nothing extra to host or secure.
• Pick MCP if the same tool should work in a coding assistant, an agent platform and your own app, or if a vendor already ships an official server for the system you need.
• Pick both if you have a few private functions and want to plug in shared servers next to them. The APIs accept the two kinds in one request.

A note on names before the detail. "Tool use", "tool calling" and "function calling" are the same feature: Anthropic's docs introduce tool use as "also called function calling", and OpenAI describes a function as one kind of tool. This page uses function calling for tools you define in the request.

MCP vs function calling, side by side

The row people skip is the one that settles most arguments: from the model's side, the two are identical. An MCP client fetches tool definitions from a server and hands them to the model as ordinary tools. What comes back is an ordinary tool call.

So MCP is not a smarter way for a model to use tools. It is a standard way to package them, so the integration is written once per system instead of once per app.

The same CRM tool, three ways

Take one read-only tool: look up a contact in a CRM by email address. The names and URLs below are illustrative, and the request shapes follow the vendors' documented examples.

1. As a function

This is the definition in Anthropic's shape. OpenAI's differs only in the envelope: a type of function, parameters instead of input_schema, and a strict flag that OpenAI recommends turning on.

{
  "name": "lookup_contact",
  "description": "Look up one CRM contact by email address. Returns the contact's name, company, account owner and deal stage. Use it when the user asks about a specific person or account. It does not search by name and it never changes data.",
  "input_schema": {
    "type": "object",
    "properties": {
      "email": {
        "type": "string",
        "description": "The contact's email address, e.g. dana@example.com"
      }
    },
    "required": ["email"]
  }
}

Your app sends this in the tools array of every request. When the model answers with a tool call for lookup_contact, your code queries the CRM with a key the model never sees and returns the row. The long description is deliberate: Anthropic calls detailed descriptions the most important factor in tool performance and suggests at least three or four sentences per tool.

2. As an MCP tool

Move the handler behind an MCP server and this is the entry a client receives from tools/list:

{
  "name": "lookup_contact",
  "title": "Look up a CRM contact",
  "description": "Look up one CRM contact by email address. Returns the contact's name, company, account owner and deal stage. Use it when the user asks about a specific person or account. It does not search by name and it never changes data.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "email": {
        "type": "string",
        "description": "The contact's email address, e.g. dana@example.com"
      }
    },
    "required": ["email"]
  }
}

Same name, same description, same JSON Schema under a different key. What changed is the owner. The server now holds the CRM credentials and runs the query, and any client that connects can call the tool without a line of integration code.

3. As both

You do not need to write an MCP client to use that server from your own backend. Anthropic's MCP connector, in beta, attaches a remote server from the Messages API request. The server goes in mcp_servers and must be referenced by an mcp_toolset entry in tools:

curl https://api.anthropic.com/v1/messages \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: mcp-client-2025-11-20" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 1000,
    "messages": [{"role": "user", "content": "Who owns the account for dana@example.com?"}],
    "mcp_servers": [
      {
        "type": "url",
        "url": "https://crm.example.com/mcp",
        "name": "crm",
        "authorization_token": "YOUR_TOKEN"
      }
    ],
    "tools": [
      { "type": "mcp_toolset", "mcp_server_name": "crm" }
    ]
  }'

Your private functions can sit in the same tools array next to the toolset. Two limits from the connector docs: it supports tool calls only, not the rest of the MCP feature set, and the server must be reachable over public HTTPS, so a local stdio server cannot be attached this way.

Token overhead: where the real difference shows up

One tool costs the same either way: its definition is input tokens on every request. OpenAI says so directly (function definitions "count against the model's context limit and are billed as input tokens"), and the same applies once an MCP tool has been loaded. The gap opens because a server hands you its whole catalogue.

Put a price on that with arithmetic from published rates. Claude Opus 5.5 lists $4 per million input tokens (checked October 2026), so 55,000 tokens of definitions is $0.22 on every uncached request, before the user's question is read. At 1,000 requests a day that is $220 a day for tool descriptions. The same block read from the prompt cache, at $0.20 per million, is about one cent.

Both vendors document the fixes, and they apply to functions and MCP tools alike:

The allowlist is the cheapest. All three APIs take one when you attach a server, and OpenAI's guide gives the reason: servers "can have dozens of tools", and exposing many of them raises cost and latency. OpenAI also suggests keeping fewer than 20 functions available at the start of a turn, as a soft target. One detail from the MCP spec helps caching: servers should return tools in a deterministic order, precisely so clients can cache the list and prompt caches keep hitting.

Auth and trust: the part that gets skipped

Function calling adds no auth surface. Your app runs the function with credentials it already has, and the model only ever sees arguments and results. If the function is dangerous, the guard is your own code.

A remote MCP server is a network service of its own, so somebody has to authenticate to it. The specification makes authorization optional and, for HTTP servers, bases it on OAuth 2.1: the server is a resource server and the client presents an access token on each request. A server may return a different tool list depending on the scopes in that token. Local stdio servers skip all this and read credentials from the environment. When you attach a server from a model API, you obtain the token yourself and pass it in a request field.

Tool calling vs MCP: what is different now

Most confusion comes from advice written when MCP was a desktop-app feature. Five assumptions from that period no longer hold.

The first row is the practical one. You can keep your own agent loop, written with plain function calling, and add an MCP server as one more entry in the request:

The stateless change matters if you host a server. In the 2026-07-28 revision each request carries its protocol version and client capabilities, and tool lists no longer vary per connection, which makes a server much easier to run behind an ordinary load balancer. OpenAI adds a billing note worth knowing: with its MCP tool you pay only for the tokens used when importing tool definitions or making tool calls, with no extra fee per call.

When to use function calling, MCP or both

Start with a function and extract it when a second consumer shows up. That order costs you nothing, because the definition carries over unchanged.

If you only consume tools, the decision is simpler: where a vendor ships an official MCP server, use it rather than wrapping the vendor's API in your own functions. Our lists of the most useful MCP servers and the best MCP servers for coding cover which ones hold up.

And if the steps never change, you may need neither. A nightly sync or a webhook handler should call the API directly from code; tools are for cases where the model decides what to do next. For the code side of each route, our Claude API function calling tutorial walks through the tool loop in TypeScript, and the AI SaaS Builder program has lessons on both halves: tool use and structured output on the Claude API, then building your first MCP server and putting MCP into a product.

Function calling vs MCP: FAQ