MCP vs Function Calling: What Changed

What Function Calling Actually Does

Function calling is a capability of the language model itself. When a model supports function calling, it can output structured JSON describing a function it wants to invoke instead of generating free text. The model does not execute anything. It generates a data structure that says "I want to call this function with these arguments," and the calling application handles the actual execution.

OpenAI introduced function calling in June 2023, and by late 2024, every major model provider supported it in some form. Anthropic's Claude calls it "tool use," Google's Gemini calls it "function calling," and open-source models through frameworks like Ollama support it as well. Despite different naming conventions, the core mechanism is consistent: the model receives function definitions, analyzes the user's request, and generates structured calls when a function would help satisfy the request.

The key insight about function calling is that it is stateless and model-specific. The model generates a tool call, but it has no knowledge of how tools are discovered, where they are located, how they are authenticated, or how results are formatted. The calling application handles all of that. Function calling provides the intent expression mechanism, and everything else is left to the application layer.

What MCP Adds

MCP provides the infrastructure layer that function calling lacks. Where function calling generates intent ("I want to query the database"), MCP handles fulfillment ("route this query to the PostgreSQL server, authenticate with the configured credentials, execute it with the appropriate permissions, and return the formatted result").

MCP adds tool discovery. Instead of hardcoding tool definitions in your application, MCP servers advertise their capabilities dynamically. When a client connects to a server, the server responds with a list of available tools, their descriptions, and their parameter schemas. The application collects tool definitions from all connected servers and passes them to the model as function definitions. If a new server is connected, its tools become available automatically without code changes.

MCP adds standardized execution. When the model generates a function call, MCP routes it to the correct server, serializes the request using JSON-RPC 2.0, handles the response, and formats the result. Error handling, timeout management, and retry logic are handled by the protocol layer rather than implemented ad-hoc for each tool.

MCP adds multi-provider compatibility. A tool defined through MCP works with Claude, ChatGPT, Gemini, and any other MCP-compatible client. Without MCP, each provider's function calling format is slightly different, requiring provider-specific tool definitions and response handling. MCP normalizes these differences so that one server implementation works everywhere.

The Two-Phase Model

The simplest way to understand the relationship is as two phases. Phase one is intent generation, where the language model uses function calling to express what action it wants to take. Phase two is fulfillment, where MCP handles discovering the tool, routing the request, executing the operation, and returning the result.

In practice, this means that MCP uses function calling internally. When an MCP client collects tool definitions from connected servers and passes them to the model, it is using the model's native function calling capability. When the model generates a tool call response, the MCP client parses it and routes it to the appropriate server. MCP builds on function calling rather than replacing it.

This layered design is important because it means MCP does not require any changes to the models themselves. Any model that supports function calling can work with MCP through a compatible client. The model does not need to know about MCP, JSON-RPC, server connections, or transport protocols. It simply receives tool definitions and generates structured calls, exactly as it does with any function calling implementation.

The Context Tax Problem

One practical advantage of MCP over raw function calling relates to context window management. With pure function calling, every tool definition must be included in every API request as part of the system message or tool parameter. A system with 50 tool definitions might consume 3,000 to 5,000 tokens just for the definitions, charged on every single request whether the model uses any tools or not.

MCP improves this situation in several ways. Dynamic tool selection means the host can analyze the user's request and include only relevant tool definitions. MCP servers can group related tools, allowing the client to selectively load tool sets based on context. Server-side filtering lets the server customize which tools are visible based on the client's declared needs. These approaches reduce the token overhead of tool definitions without sacrificing tool availability.

Additionally, prompt caching features offered by providers like Anthropic reduce the repeated cost of tool definitions across turns in a conversation. The tool definitions are cached after the first request, and subsequent requests pay a fraction of the original token cost. Combined with MCP's dynamic tool selection, this makes large tool ecosystems economically viable.

When Function Calling Alone Is Enough

Function calling without MCP is sufficient for simple systems with a small, fixed set of tools, a single model provider, and a single application managing everything. If you have five tools hardcoded in your application, you do not need MCP's discovery mechanism. If you only use Claude, you do not need MCP's multi-provider compatibility. If your tools never change, you do not need dynamic capability negotiation.

MCP adds value when any of these conditions change: when you need more than a handful of tools, when you want tools to work across providers, when tools change dynamically, when multiple applications need to share tools, or when you want a consistent security and governance model across all tool integrations. For most systems that grow beyond initial prototypes, MCP's infrastructure pays for itself quickly.

The Convergence

The industry has largely converged on using both together. OpenAI's deprecation of its Assistants API in favor of MCP, combined with every major provider's adoption of MCP client support, confirms that MCP is the standard infrastructure for tool integration while function calling remains the standard mechanism for tool invocation. They are complementary layers, and understanding both is necessary for building capable AI agent systems in 2026.