Tool Calling vs. MCP: Differences and When to Use Each

Tool calling is a language model API feature where the model requests a function call and your application runs the code. Model Context Protocol (MCP) is an open JSON-RPC standard that lets AI applications discover and invoke tools exposed by external servers. MCP relies on tool calling underneath rather than replacing it.

Developers building AI agents or LLM-powered backends frequently run into both terms in vendor documentation. Understanding tool calling vs MCP comes down to separating how a model decides to run a function from how an application connects to the system where that function lives.

What Is Tool Calling in LLM APIs?

Tool calling (also called function calling) is a model API feature that turns a natural language prompt into a structured function invocation. You pass function definitions in your API request using a name, description, and JSON Schema parameters, and the model decides whether to return a structured call containing the function name and arguments.

The model does not execute the function itself. Instead, tool calling works as a multi-step conversation between your application and the model:

Send tool declarations: Your application requests the model and includes the JSON Schema definitions of the tools the model could call.
Receive a structured tool call: The model responds with a tool call containing the chosen function name and JSON arguments (for example, Anthropic returns a tool_use stop reason and block).
Execute code on the application side: Your backend validates the arguments and runs the local function or internal API request.
Return the tool output: Your application makes a second request to the model containing the result (such as a tool_result block).
Receive the final response: The model uses the output to answer the user or requests additional tool calls.

An OpenAI function definition uses JSON Schema parameters and supports strict: true to enforce schema adherence:

{
  "type": "function",
  "name": "get_weather",
  "description": "Get the current weather for a given location.",
  "strict": true,
  "parameters": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string"
      }
    },
    "required": ["location"],
    "additionalProperties": false
  }
}

Major model APIs give you granular control over how the model selects functions. In OpenAI and Google Gemini APIs, tool_choice lets you leave selection on auto (the default), force one or more calls (required in OpenAI, any in Gemini), disable tools (none), restrict the model to a subset with allowed_tools, or use Gemini’s validated mode to ensure function schema adherence. Both OpenAI and Gemini support parallel function calling so a model can invoke multiple functions in a single turn, and OpenAI lets you set parallel_tool_calls to false when you want at most one call per turn. Gemini also supports compositional calling for sequential multi-step executions.

Anthropic splits tool use by where the code runs. Client tools (which include your custom functions and Anthropic-schema tools like bash and text_editor) run inside your application. Server tools (such as web_search, web_fetch, code_execution, and tool_search) execute directly on Anthropic infrastructure.

What Is the Model Context Protocol (MCP)?

The Model Context Protocol (MCP) is an open-source standard for connecting AI applications to external systems over JSON-RPC 2.0. Inspired by the Language Server Protocol, the MCP specification (version 2026-07-28) acts like a USB-C port for AI applications so a single server integration can work across ChatGPT, Claude, Visual Studio Code, Cursor, and custom agents.

MCP separates responsibilities across three roles:

Hosts: The LLM applications (such as an IDE or chat interface) that initiate connections.
Clients: The protocol connectors running inside the host application.
Servers: External services that expose capabilities and context to the client.

In the 2026-07-28 specification, the base protocol uses stateless, self-contained JSON-RPC 2.0 requests with per-request capability negotiation. MCP defines two standard transports: stdio, which passes newline-delimited messages over standard input and output of a client-launched subprocess, and Streamable HTTP, where each message is an HTTP POST to a single MCP endpoint. Developers can also implement custom transports.

While LLM tool calling only handles functions, MCP servers can expose three core features:

Tools: Functions for the AI model to execute.
Resources: Context and data that the application can read.
Prompts: Templated messages and workflows for users.

On the client side, MCP supports Elicitation, which lets a server initiate requests for additional information from the user. The 2026-07-28 spec also includes opt-in negotiated extensions for Tasks (asynchronous long-running operations), Skills over MCP, and MCP Apps (interactive UI elements rendered inline).

For tool execution specifically, an MCP client discovers available tools by calling tools/list, which supports pagination and caching. Servers that declare the listChanged capability can notify clients whenever their available tools change. Each MCP tool definition includes a case-sensitive name (recommended to be 1 to 128 characters), an optional title, description, optional icons, an inputSchema (defaulting to JSON Schema 2020-12), an optional outputSchema, and optional annotations.

When the model decides to use an MCP tool, the client sends a tools/call JSON-RPC request to the server:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "San Francisco, CA"
    }
  }
}

If a tool execution fails on the server, MCP returns the error inside the result with isError: true so the language model can read the failure and self-correct.

Tool Calling vs. MCP: Side-by-Side Comparison

Comparing LLM tool calling vs MCP directly highlights how the two operate at different layers of the stack. As of November 2026, here is how native tool calling and the Model Context Protocol differ across seven architecture dimensions:

Dimension	Tool Calling (Function Calling)	Model Context Protocol (MCP)
What it is	Model API feature where an LLM outputs structured function arguments	Open JSON-RPC 2.0 protocol connecting AI hosts and clients to external servers
Who defines tools	Your application code (or vendor server tools) in the model API request	An MCP server exposing tools, resources, and prompts
Where code runs	Your application backend (or the LLM vendor’s cloud for server tools)	A local subprocess (`stdio`) or a remote service (Streamable HTTP)
Discovery	Static per API request; your code hardcodes or selects schemas before calling the model	Dynamic at runtime via `tools/list` and `listChanged` notifications
Transport	Vendor HTTPS API (OpenAI, Anthropic, Google Gemini)	`stdio`, Streamable HTTP, or custom transports
Portability across clients	Tied to your app and the specific LLM vendor’s schema format	Portable across any MCP-compatible host (Claude, ChatGPT, VS Code, Cursor, custom apps)
What it costs	Input tokens for tool definitions, output tokens for calls, plus extra fees for vendor server tools	Input tokens for every loaded tool schema, plus infrastructure to host or run the MCP server

Does MCP Replace Function Calling?

MCP does not replace function calling because the language model still uses tool calling to select and invoke every MCP tool. Tool calling and MCP are complementary layers in the same request lifecycle.

When an AI application connects to an MCP server, the workflow combines both systems:

Discovery via MCP: The host application’s MCP client sends a tools/list request to the MCP server and receives the server’s tool names, descriptions, and JSON Schema inputSchema objects.
Formatting for the LLM: The host translates those MCP tool definitions into the LLM vendor’s native tools array and sends them alongside the user prompt.
Selection via Tool Calling: The language model evaluates the prompt and emits a standard tool call with the chosen tool name and arguments.
Execution via MCP: The host catches the model’s tool call, maps it to an MCP tools/call request, and sends it to the MCP server over stdio or Streamable HTTP.
Completion: The MCP server returns the result (with isError: true if execution failed), the host passes that output back to the model as a tool result, and the model generates its final answer.

Without tool calling inside the model API, the LLM would have no mechanism to trigger an MCP tool. Without MCP, your application has to wire up every tool schema and execution handler manually.

How Do OpenAI, Anthropic, and Google Support MCP Directly?

OpenAI, Anthropic, and Google now let you pass remote MCP servers directly into their model APIs as a built-in tool type. Instead of writing your own MCP client loop to bridge tools/list and tools/call, the model provider’s API connects to the MCP server on your behalf.

As of November 2026, each vendor implements direct MCP server connections with specific capabilities and documented limits:

OpenAI Responses API

In the OpenAI Responses API, you can attach an MCP server by specifying "type": "mcp" in your tools array along with server_label and server_url. OpenAI includes two key controls for production deployments:

allowed_tools: Imports only a specific subset of tools from the MCP server so you do not overload the model context.
require_approval: Configures whether tool invocations run automatically or pause for explicit human approval.

For local or private services, OpenAI provides a Secure MCP Tunnel so you can connect internal MCP servers without exposing them on the public internet.

Anthropic MCP Connector

Anthropic offers a beta MCP connector in the Messages API (mcp_servers and mcp_toolset) that connects to remote MCP servers without requiring a separate client implementation. Keep four documented limitations in mind:

Tools only: Only tool calls from the MCP specification are supported through the connector (not MCP resources or prompts).
Public HTTP required: The MCP server must be publicly exposed over HTTP (supporting Streamable HTTP and SSE).
No direct local stdio: Local stdio servers cannot connect directly to the Messages API, though Anthropic’s SDKs provide client-side helpers for local servers.
Compliance exclusions: The beta MCP connector is not eligible for Zero Data Retention (ZDR) or HIPAA workloads.

Google Gemini Interactions API

Google’s Gemini Interactions API accepts external MCP servers using the "type": "mcp_server" declaration, configured with name, url, headers, and allowed_tools. Google enforces two strict rules on this integration:

Streamable HTTP only: The Gemini Interactions API supports Streamable HTTP servers and does not support SSE transports.
Naming syntax: Server names must use snake_case and cannot contain hyphens.

When Should You Use Tool Calling vs. MCP?

Choosing when to use MCP vs tool calling depends on who maintains the integrations and how many applications need to share them. Look at your project constraints across three common patterns.

When Plain Tool Calling Is Enough

Stick with native LLM tool calling when your tools live inside a single application backend and no external client needs to call them. If I am building a web app with five internal database queries and a Stripe checkout action, writing an MCP server adds an unnecessary network hop or subprocess.

Plain tool calling is the better fit when:

You only have a small number of functions that query your own database or internal microservices.
You control the entire codebase and want tight latency and direct in-process validation.
No other AI assistant, IDE, or team needs to discover or reuse those functions.

When an MCP Server Pays Off

Build or adopt an MCP server when the same tools need to work across multiple AI clients or when another team owns the underlying system. If your engineering platform exposes issue tracking and deployment logs over MCP, developers can attach that exact same server to Claude, ChatGPT, Visual Studio Code, Cursor, and your internal agent without rewriting schemas.

MCP pays off when:

You want write-once portability across multiple AI hosts and developer IDEs.
A third-party vendor or a separate internal team maintains the integration.
Your agent relies on dynamic tool discovery (tools/list and listChanged) as capabilities change at runtime.
Your workflow needs MCP resources, user-facing prompt templates, or user elicitation alongside function execution.

The Hybrid Setup

A common pattern for teams moving AI agents from pilot to production is to combine both approaches. A typical application defines a handful of latency-sensitive, native function tools in code while attaching one or two external MCP servers for third-party SaaS integrations, using allowed_tools to filter out unnecessary endpoints.

Security, Latency, and Token Cost Tradeoffs

Adding tools to an LLM application, whether through native declarations or MCP servers, introduces token costs, caching considerations, and security boundaries that you need to manage carefully.

Input Token Costs and Prompt Caching

Every tool definition you pass to a model API counts toward your input tokens. Anthropic documents that tool definitions in the tools parameter count as input tokens, and OpenAI notes that some MCP servers expose dozens of tools at once, where exposing many tools can raise both cost and latency.

To keep token bills predictable:

Filter the imported tools: OpenAI and Google use allowed_tools, while Anthropic’s MCP connector lets you allowlist, denylist, or configure individual tools in the mcp_toolset.
Keep tool list ordering deterministic. The MCP specification notes that deterministic ordering in tools/list helps clients cache the tool list and improves LLM prompt caching hit rates when tool definitions are placed in the model context.

Trust Boundaries and Human Approval

Tools represent arbitrary code execution, a concern that becomes even sharper if you also deploy computer use AI agents that interact with full operating systems. When you connect a third-party MCP server, you cross a trust boundary where untrusted tool descriptions or server responses can act as a vector for prompt injection.

The MCP specification explicitly warns that tool annotations must be treated as untrusted unless they come from a trusted server. Because MCP cannot enforce safety at the wire protocol level, the specification states that host applications must obtain explicit user consent before invoking any tool and should always keep a human in the loop with the ability to deny invocations. When using direct API integrations like OpenAI’s Responses API, enable require_approval on sensitive tools so a human can review arguments before execution.

FAQ

Is MCP the same as function calling?

No. Function calling (tool calling) is the model API mechanism where an LLM outputs a structured JSON request to run a named function. The Model Context Protocol (MCP) is an open communication standard that lets AI applications discover and invoke tools, resources, and prompts hosted on external servers.

Can you use MCP without tool calling?

You can use MCP resources and prompt templates without model tool calling, since those features are read or triggered by the host application or user. However, whenever an AI model autonomously invokes an MCP tool via tools/call, the model uses its native tool calling capability underneath to select that tool.

Does using MCP cost more tokens than native tool calling?

An individual tool definition costs the same number of input tokens whether your app loads it from local code or from an MCP server. MCP setups often consume more tokens in practice because a single MCP server can expose dozens of tools at once, unless you filter the list using allowed_tools.

Which LLM providers support MCP servers natively in their APIs?

As of November 2026, OpenAI, Anthropic, and Google all accept remote MCP servers directly in their APIs. OpenAI supports "type": "mcp" in the Responses API, Anthropic offers the beta MCP connector (mcp_servers and mcp_toolset) in the Messages API, and Google supports "type": "mcp_server" in the Gemini Interactions API.

Can Anthropic’s API connect to a local stdio MCP server directly?

No. Anthropic’s beta MCP connector in the Messages API only connects to remote MCP servers that are publicly exposed over HTTP (Streamable HTTP and SSE). To use a local stdio MCP server with Claude, you must run the connection on the client side using Anthropic’s SDK helpers.

Tool Calling vs. MCP: How They Differ and When to Use Each

What Is Tool Calling in LLM APIs?

What Is the Model Context Protocol (MCP)?

Tool Calling vs. MCP: Side-by-Side Comparison

Does MCP Replace Function Calling?