MCP vs function calling: where tools come from and who runs them

Function calling (also called tool use) is for letting a language model ask the application around it to run a function: the model returns a structured call, and code outside the model executes it. MCP (Model Context Protocol) is for connecting that application to separate servers that offer tools, data and prompts, over a standard protocol that any host and any server can share.

They work at different layers. Function calling is a feature of each provider’s model API, between your application and the model. MCP is an open protocol between your application and a tool server. Most MCP hosts use both: MCP to learn what tools exist and to call them, function calling to let the model choose among them.

Status as of September 26, 2026. MCP’s current specification version is 2026-07-28. MCP is hosted by Model Context Protocol a Series of LF Projects, LLC, under the Linux Foundation, with its own maintainer governance. Function calling has no shared specification. Each provider defines its own request and response shapes, and the three documented here (OpenAI, Anthropic and Google Gemini) differ in field names.

What function calling is for

A model cannot open a database connection or call an API. Function calling gives it a way to ask. The flow is the same across providers:

1. Your request includes tool definitions: a name, a description and a JSON Schema for the arguments.
2. The model decides whether a tool would help. If so, it returns a call with the tool name and arguments instead of, or before, a final answer.
3. Your code runs the function.
4. You send the result back in the next request, and the model continues.

The shapes differ by provider:

	OpenAI	Anthropic	Google Gemini
Tool definition	type: "function", name, description, parameters (JSON Schema), optional strict	name, description, input_schema, optional strict	Function declaration with name, description, parameters
Model’s call	A function_call item with call_id, name and arguments	A tool_use block with id, name and input, and stop_reason: "tool_use"	A function call with name and arguments
Your reply	A function_call_output item with the same call_id	A tool_result block with the matching tool_use_id	A function result
Choosing tools	tool_choice: auto, required, none, a named function, or allowed_tools	tool_choice: auto, any, a named tool, or none	Modes auto, any, none and validated

Some tools do not run in your code. Anthropic distinguishes client tools, which your application executes, from server tools such as web search, which run on Anthropic’s infrastructure. OpenAI also offers built-in tools. For your own functions, though, the model only produces the call. Execution, permissions and side effects are yours.

What MCP is for

MCP gives an AI application a standard way to reach capabilities it does not contain. It has three roles: the host (the AI application), a client inside the host for each connection, and a server that exposes features. Servers offer tools (functions the model can call), resources (data) and prompts (templates). Clients can offer elicitation, so a server can ask the user for input.

For tools, the protocol defines two main requests. tools/list returns the server’s tools, each with a name, a description, an inputSchema (JSON Schema, 2020-12 by default) and optionally an outputSchema and annotations. tools/call invokes one by name with arguments, and returns content blocks, optional structuredContent, and isError for failures the model can correct. Messages are JSON-RPC 2.0 over stdio for local servers or Streamable HTTP for remote ones. HTTP servers can require authorization through an OAuth 2.1 profile. In the 2026-07-28 revision every request is self-contained and carries its own protocol version and client capabilities.

The MCP specification calls tools model-controlled: they exist to be offered to a language model. That is the link between the two layers.

Side by side

	Function calling	MCP
Purpose	Let the model request a function call during a conversation	Let an AI application discover and use tools, data and prompts on separate servers
Layer	Feature of a model provider’s API	Open application protocol
Who talks to whom	Your application and the model API	An MCP client in the host and an MCP server
Transport	Inside the provider’s HTTPS API	JSON-RPC 2.0 over stdio or Streamable HTTP
Discovery	None; your application sends tool definitions with each request	tools/list for tools, resources/list for data; list-changed notifications
Auth	Your API key to the provider; tool credentials are your code’s business	Optional; OAuth 2.1 profile for HTTP servers, environment credentials for stdio
State	The conversation your application resends	Stateless requests in 2026-07-28; servers can return explicit handles for stateful tools
Governance and status	Defined separately by each provider; no common specification	Hosted by a Series of LF Projects, LLC; version 2026-07-28

How they fit together

An MCP host bridges the two. Illustrative flow for a weather tool:

1. The host’s MCP client sends tools/list and receives this definition:

{
  "name": "get_weather",
  "description": "Get current weather information for a location",
  "inputSchema": {
    "type": "object",
    "properties": { "location": { "type": "string", "description": "City name or postal code" } },
    "required": ["location"]
  }
}

2. The host converts it into the provider’s format. For OpenAI’s Responses API:

{
  "type": "function",
  "name": "get_weather",
  "description": "Get current weather information for a location",
  "parameters": {
    "type": "object",
    "properties": { "location": { "type": "string", "description": "City name or postal code" } },
    "required": ["location"]
  }
}

For Anthropic’s Messages API the same schema goes under input_schema instead of parameters, with no type field.

3. The model returns a call for get_weather with {"location": "Toronto"} as arguments.
4. The host checks its policy, asks the user if needed, and sends the MCP request. The _meta request metadata is omitted here, as the MCP specification’s own examples do:

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

5. The host returns the MCP result to the model as the function output.

Providers now offer to do steps 1 to 5 for you. OpenAI’s function calling guide lists remote MCP servers as a tool type, Anthropic has an MCP connector for its Messages API, and Google’s Gemini documentation shows an MCP server tool. The provider then acts as the MCP client, which also means your MCP server receives calls from the provider’s infrastructure.

When to use each

Function calling alone fits when the tools belong to one application: a few functions in the same codebase, one model provider, no need to share the tools elsewhere.

MCP fits when tools should be reusable across hosts and models, when another team or vendor maintains them, or when a server should work with any MCP-capable client. You write the integration once and every compatible host can use it.

Both is the normal case for an MCP host. MCP supplies the tools, and function calling is how the model picks one.

Common misconceptions

“MCP replaces function calling.” MCP needs function calling, or something like it, to let the model choose a tool. It standardizes the other side: where tools come from and how they are invoked.

“Function calling is a standard.” It is a common pattern with provider-specific formats. A tool definition written for one API needs converting for another.

“The model runs the tool.” For your own functions the model only emits the call. Your code, or your MCP server, performs the action.

“An MCP tool list is safe to trust.” The MCP specification says clients must treat tool annotations as untrusted unless they come from a trusted server, and that a human should be able to deny tool calls. Descriptions from an unknown server can carry instructions aimed at the model.

“MCP connects agents to agents.” MCP connects an application to tools and data. For handing work to an independent agent, see A2A vs MCP.