MCP vs Function Calling: What Is the Difference?

The Short Answer

Function calling (also called tool use) is a model API feature. It is the mechanism by which an LLM signals “I want to invoke this tool with these arguments.” Your application code does the actual work and returns the result to the model.

MCP (Model Context Protocol) is an open connectivity protocol. It is a standard for packaging tool logic into reusable servers that any compatible client can discover and connect to, over a defined transport such as stdio or HTTP.

Function Calling: the Model-Level Mechanism

When you call a modern LLM API you can pass a list of tool definitions alongside your prompt. Each definition describes a callable function: its name, a description the model can read, and a schema for its parameters (typically expressed as a JSON Schema object).

When the model decides a tool is useful, it does not execute any code itself. Instead it produces a structured response that names the tool and provides the arguments. Your application catches that response, runs the actual function, and sends the result back to the model as a subsequent message. The model then continues reasoning from there.

Function calling is entirely self-contained inside a single API exchange. You declare tools in the request, handle the model's tool-call output in your code, return results, and repeat as needed. Everything lives inside your application process.

A simplified function-calling exchange

// 1. Your application sends to the model API:
{
  "tools": [
    {
      "name": "get_weather",
      "description": "Get current weather for a city.",
      "input_schema": {
        "type": "object",
        "properties": { "city": { "type": "string" } },
        "required": ["city"]
      }
    }
  ],
  "messages": [{ "role": "user", "content": "What is the weather in Muscat?" }]
}

// 2. The model responds with a structured tool call (not plain text):
{
  "type": "tool_use",
  "name": "get_weather",
  "input": { "city": "Muscat" }
}

// 3. Your code runs get_weather("Muscat") and sends the result back.
// 4. The model produces a final text response for the user.

MCP: the Open Tool-Server Protocol

The Model Context Protocol (MCP) is an open standard that defines how AI clients connect to tool servers. A tool server is a separate process that exposes tools, data resources, and prompt templates over a well-defined protocol. Any compatible client can connect to any conforming server.

The protocol is built on JSON-RPC 2.0 as its message format. The spec defines two transports:

• stdio — the client launches the server as a child process and communicates over its standard input and standard output. Common for local development tools and desktop applications.
• Streamable HTTP — the server runs as an HTTP service; the client sends requests over HTTP and receives streaming responses. This current transport supersedes the older SSE-only transport. Suitable for remote or shared servers.

When a client connects to an MCP server, the two parties perform a capability handshake. The server advertises what it can offer. The client then knows what tools are available and can present them to a model — via that model's own function-calling mechanism.

What an MCP server can expose

• Tools — callable functions. These are what get surfaced to the model through function calling.
• Resources — readable data (files, database rows, API snapshots) the client can inject into context.
• Prompts — reusable prompt templates the client can invoke by name.

How They Relate: the Full Picture

Here is what happens when a user interacts with an MCP-enabled AI client, such as a desktop application or an IDE extension:

In short: MCP is the wiring that connects reusable tool servers to AI clients. Function calling is what happens at the model layer once those tools are wired up. They are complementary layers, not competing approaches.

Side-by-Side Comparison

Dimension	Function Calling	MCP
What it is	A model API feature	An open connectivity protocol
Where tool logic lives	Inside your application code	A separate server process
Transport	None — definitions sent inline in the API request	JSON-RPC 2.0 over stdio or HTTP
Tool discovery	You write and maintain tool definitions	Client discovers tools automatically via handshake
Reusability	Tied to the application that defines them	Any compatible client can connect to the same server
Who executes the call	Your application code	The MCP server process
Best for	In-app tools, simple integrations	Shared tooling across clients, ecosystem servers

When to Use Each

A Note on Terminology

Different API providers use slightly different names for the same underlying concept. Anthropic's API calls it tool use; OpenAI's API calls it function calling. The mechanics are similar in both cases: pass tool schemas in the request, receive structured tool-call outputs, return results, and continue. The term “function calling” has become common shorthand for this model-level mechanism regardless of provider.

MCP was designed to be model-agnostic. An MCP server does not care which model or provider the client is using. The protocol speaks JSON-RPC, not anything model-specific. Whether the client routes an MCP tool to one model or another is up to the client application, not the server.

When you see tools arrays inside API request bodies, you are looking at function calling. When you see mcpServers config entries, stdio transport references, or separate server processes being launched, you are looking at MCP — and the underlying model is still using function calling one layer below.

Frequently Asked Questions