MCP vs Function Calling: Differences and Use Cases

Written by

Rajni

Reviewed by

Himanshu

Published 05 November 2026

Expert Verified

Quick Answer: Function calling is how a model asks for a tool, and MCP is how an application finds and runs tools on a server. They are two layers of one request, so a single agent can use both. Use function calling alone for a few tools private to one application, and add MCP when a second client or another team needs the same tools.

TL;DR

• Function calling is a model feature. The model returns a structured request, a message in a fixed format, to call a tool, which is any operation you expose to it. Your own code runs the tool.
• MCP, the Model Context Protocol, is an open protocol for finding and calling tools on external servers. An MCP-aware app typically hands those tools to the model through function calling.
• In the MCP vs function calling choice, MCP adds a server to secure and a longer tool list to pay for in tokens. Filter the tools you expose, and require approval for any call that changes data.

An AI agent can answer questions, but what happens when it needs to check an order, update a customer record, or retrieve information from another application?

To perform these actions, AI models need access to external tools and systems. Two common approaches are function calling and the Model Context Protocol (MCP). Both help AI applications work with external tools, but they serve different purposes.

Function calling allows an AI model to request a specific operation, such as checking an order status, while the application executes it and returns the result. MCP provides a standardized way for AI applications to discover and connect with tools, data sources, and services without building separate integrations for every client.

The important difference is that MCP and function calling aren’t competing technologies. They can work together in the same AI agent, with function calling handling the model’s tool requests and MCP supporting communication with external tool servers.

In this guide, we’ll compare MCP vs function calling, explain how each works, and examine their differences in architecture, security, performance, and token costs. You’ll also find practical examples and use cases to help you decide when to use function calling, MCP, or both in your AI applications.

---

MCP vs Function Calling: Key Differences at a Glance

MCP and function calling both allow AI agents to work with external tools, but they differ in how those tools are defined, accessed, and executed. The table below highlights their key differences.

Feature	Function Calling	MCP (Model Context Protocol)
Purpose	Allows AI models to request specific tool operations	Connects AI applications to external tools and data sources
Tool definition	The application provides tool names, descriptions, and parameters	The MCP server exposes available tools through tools/list
Tool execution	Application code executes the requested function	The MCP server executes the requested tool
Tool discovery	The application selects which tools to provide	The MCP client discovers tools from the connected server
Portability	Tool-calling formats differ between model providers	Uses a standard protocol across compatible clients and servers
Authorization	Relies on the application’s existing access controls	Supports OAuth-based authorization for remote servers

A client is the part of an application that connects to one tool server. tools/list is the request that returns a server’s tool menu. OAuth is a standard that lets an app act for a user without handling the user’s password.

What Is Function Calling in AI?

Function calling lets a model ask for work it cannot do from text alone, such as reading an order record or sending an email. It is the mechanism that lets AI agents act as well as answer. An agent is software that uses a model to decide on and carry out steps.

Function calling is also called tool calling, and Anthropic names the same feature tool use. Google’s Gemini API calls it function calling too, so MCP vs tool calling and MCP vs function calling are the same comparison.

How Function Calling Works

Every provider runs the same loop, and your application owns it.

1. Your application sends the user’s message plus a list of tool definitions, each with a name, a description, and a JSON Schema for the arguments.
2. The model replies with a tool call that names a tool and fills in the arguments.
3. Your code runs the operation, because the model never executes anything on its own.
4. Your application sends the result back, tied to the call by an ID.
5. The model writes the final answer or asks for another tool.

The shapes differ by provider. OpenAI defines a tool with parameters and an optional strict flag that forces arguments to match the schema. Anthropic uses input_schema and answers a tool_use block with a tool_result block. Gemini answers a function_call step with a function_result. OpenAI recommends enabling strict mode and bills function definitions as input tokens, so a long tool list costs money before the model does anything.

Function Calling Limitations

The feature says nothing about where tools live, how they are found, or how they are shared. Each provider expects its own request and response shapes, so the same order-lookup tool needs one wrapper per provider. A wrapper is a small adapter that converts the tool into that provider’s format. Each vendor’s flagship models, such as GPT-6 Astra and Claude Fable 5.1, follow that vendor’s format, and GPT-6 Astra requires OpenAI’s Responses API for tool calling.

That gap shows up the first time a second provider or application joins your project, and MCP fills it.

What Is MCP (Model Context Protocol)?

MCP moves the tool definition and the tool code out of your application and behind a standard interface.

Where MCP came from

Anthropic open-sourced MCP on November 25, 2024 to replace a custom integration for every data source with one protocol. The official docs compare it to a USB-C port for AI applications. Anthropic donated it to the Linux Foundation’s Agentic AI Foundation on December 9, 2025. By then more than 10,000 active public MCP servers existed, and ChatGPT, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code had adopted it.

MCP Hosts, Clients, and Servers

A host is the AI application, such as Claude Desktop or Visual Studio Code. It creates one client for each server it connects to. Each client keeps a dedicated connection to its server, the program that provides tools and data. The model never talks to a server directly because the host sits in the middle. That split between hosts, clients, and servers lets one server serve many applications.

Messages use JSON-RPC 2.0, a lightweight request and response format built on JSON, and travel over one of two transports, which are the channels that carry messages. The stdio transport, named for standard input and output, links a local process on the same machine. Streamable HTTP carries messages to remote servers over the web.

MCP Tools, Resources, and Prompts

A server can offer three things. Tools are executable functions, resources are data the model can read, and prompts are reusable templates. Function calling maps onto tools, so you will work almost entirely with tools. A client finds tools with a tools/list request and runs one with tools/call. The specification covers only how context is exchanged, so the choice of which tool to call stays with the model and the host.

How MCP and Function Calling Work Together

An MCP host typically uses function calling to show tools to the model and to receive the model’s choice. MCP handles the steps on either side of that exchange.

1. The host’s MCP client sends tools/list to the server and receives each tool’s name, description, and input schema.
2. The host converts those definitions into the provider’s function calling format and sends them with the user’s message.
3. The model returns a tool call, which is plain function calling.
4. The host sends a tools/call request to the server that owns that tool, with the arguments.
5. The server runs the tool and returns a result, which the host passes back to the model.

Steps 2 and 3 are function calling, and steps 1, 4, and 5 are MCP.

One Tool, Defined Both Ways

The order lookup below is an invented example, but the field names follow the vendor documentation. A function calling definition in OpenAI’s Responses API format looks like this:

{

“type”: “function”,

“name”: “get_order_status”,

“description”: “Look up the shipping status of an order by order ID.”,

“parameters”: {

“type”: “object”,

“properties”: {

“order_id”: { “type”: “string”, “description”: “The order ID, for example 4812” }

},

“required”: [“order_id”],

“additionalProperties”: false

},

“strict”: true

}

The same tool as an MCP server lists it, in a tools/list result:

{

“name”: “get_order_status”,

“title”: “Order Status”,

“description”: “Look up the shipping status of an order by order ID.”,

“inputSchema”: {

“type”: “object”,

“properties”: {

“order_id”: { “type”: “string”, “description”: “The order ID, for example 4812” }

},

“required”: [“order_id”]

}

}

When the model picks the tool, the host sends this request to the server:

{

“jsonrpc”: “2.0”,

“id”: 2,

“method”: “tools/call”,

“params”: {

“name”: “get_order_status”,

“arguments”: { “order_id”: “4812” }

}

}

The server answers with a result the host passes to the model:

{

“jsonrpc”: “2.0”,

“id”: 2,

“result”: {

“resultType”: “complete”,

“content”: [

{ “type”: “text”, “text”: “Order 4812 shipped on 9 October and is out for delivery.” }

],

“isError”: false

}

}

The schema is the same JSON Schema under three names, parameters, input_schema, and inputSchema. What differs is the wrapper around it and where the code lives, which is your application for function calling and a server for MCP. The 2026-07-28 specification also requires per-request metadata, namely the protocol version and the features the client supports, and that metadata is trimmed from the request above.

The same tool, run through the official MCP Python SDK version 2.2.0 over stdio, returned these fields, including name, description, inputSchema, and resultType. That run negotiated protocol version 2025-11-25, so check your own SDK version against the 2026-07-28 revision.

How AI Model APIs Connect to MCP Servers

OpenAI’s and Anthropic’s APIs accept remote MCP servers, which you reach over the internet, so the tool loop can run inside the vendor API.

• OpenAI Responses API: the mcp tool takes a server_url and imports the server’s tool list as an mcp_list_tools item. It asks for approval before data goes to the server unless you turn that off, and an allowed_tools list limits which tools are imported.
• Claude Messages API: the MCP connector is in beta, so it can still change. It connects to remote servers by URL and supports tool calls only. An mcp_toolset object sets per-tool allowlists and denylists, which are lists of tools to allow or block. A newer beta header pins a server’s tool list so it cannot change mid-conversation.

The agent layer above both, including the agent-to-agent protocol A2A, is covered in MCP vs agentic AI, so this guide stays on the tool layer.

MCP vs Function Calling: Key Differences

MCP and function calling both connect AI models to external tools, but they differ in tool management, discovery, and security. Here are the three main differences.

1. Tool Ownership and Portability

With function calling, your application defines and executes tools. Updates happen within the application, and other clients may need separate integrations.

With MCP, a server exposes tools to multiple AI clients. Changes can be shared without rebuilding each integration.

Best fit: Function calling suits single applications, while MCP works better when multiple clients need the same tools.

2. Tool Discovery and State

Function calling requires applications to provide tool definitions. MCP allows clients to discover available tools dynamically through tools/list.

The July 2026 MCP specification introduced stateless requests, removed protocol-level sessions and the initialization handshake, and added tool-list caching support. Applications can still maintain state using identifiers passed between calls.

Best fit: MCP supports shared, changing tool catalogs. Function calling suits applications with predefined tools.

3. Authorization and Security

Function calling uses the application’s existing credentials and permissions.

MCP adds a client-server security boundary. Authorization is optional, but protected HTTP servers follow the MCP OAuth 2.1 framework. Stdio-based servers typically use environment variables for credentials.

Best fit: Function calling offers direct control over tool access. MCP requires separate server permissions and token management.

MCP vs API: What’s Different?

An API exposes operations that software can call. Function calling lets an AI model request those operations within an application, while MCP makes tools discoverable and accessible across compatible AI clients.

For example, both approaches can connect to the same CRM API. Function calling integrates it into one application; MCP can expose it to multiple AI clients through a shared server.

MCP does not replace APIs. It provides a standard interface for AI applications to use them.

MCP vs Function Calling: Token Cost and Latency

Both approaches place tool definitions in the model’s context window, the amount of text a model can read at once. Every token spent on definitions is unavailable for the task.

How Tool Definitions Affect Token Usage

Anthropic’s measurements of a five-server MCP setup and of on-demand tool loading show the scale. On-demand loading is Anthropic’s Tool Search Tool, which keeps the tool catalog outside the context and loads only the definitions the model looks up.

• Definitions alone: 58 tools across five servers use about 55K tokens before the conversation starts, and definitions have reached 134K tokens before optimization.
• On-demand loading: in a 50-plus tool example, context use fell from about 77K tokens to about 8.7K, an 85% reduction.
• Accuracy: on MCP evaluations, Opus 4 rose from 49% to 74% and Opus 4.5 from 79.5% to 88.1% with tool search enabled.

These are Anthropic’s results on its own models and its own tool search product, so read them as one vendor’s measurement.

The bill depends on how many definitions reach the model, whichever layer delivers them. With function calling you send only the tools a request needs. An MCP client imports whatever a server lists, so a server that lists 35 tools adds 35 definitions unless you filter with the allowlists described earlier. The MCP project recommends progressive tool discovery once definitions take roughly 1% to 5% of the context window. The host then fetches definitions through tools/list but injects them only as the model needs them. A hosted gateway such as MCP360, which puts 100+ tools behind one MCP endpoint, is the many-tools case where this filtering matters most.

Function Calling vs MCP Latency

Latency is the delay before a result comes back, and the transport sets its floor. A local test with the MCP Python SDK 2.2.0 timed 300 calls to the order-lookup tool on a 2-CPU Linux container.