MCP vs Function Calling: Which One Do You Actually Need?

MCP and function calling are not competing choices, and most comparisons get that wrong. Function calling is how one model decides, mid-generation, that it needs a tool and emits a structured call for it. The Model Context Protocol (MCP) is how a tool is exposed over the wire so any compatible client can discover it and run it. Different layers. A working agent normally uses both at once.

The rule, in one sentence: write a plain function-calling loop when you own both the model loop and the tool code, and add MCP when a tool has to be reachable by a client you did not write.

What does function calling do?

Function calling is a model API feature. You send tool definitions alongside the prompt, each carrying a name, a description, and a JSON Schema for its parameters.

OpenAI's guide states it without ceremony: a tool call is "a special kind of response we can get from the model if it examines a prompt, and then determines that in order to follow the instructions in the prompt, it needs to call one of the tools we made available to it." That guide documents the loop in five steps, and step three is your own code running with the arguments the model produced (OpenAI function calling guide).

Anthropic treats the two names as one thing: "Tool use (also called function calling) lets Claude call functions that you define or that Anthropic provides." The model returns stop_reason: "tool_use", your code executes the operation, and you return a tool_result block (Anthropic tool use docs).

Note what the model never does. It does not open a socket, read a file, or call an API. It emits a name and a JSON object. Execution is yours, and so is the transport, because there is no transport.

What does MCP do?

MCP is a wire protocol, not a model feature. The current revision, 2026-07-28, describes "a client-host-server architecture where each host can run multiple client instances", built on JSON-RPC, and states that "MCP is a stateless protocol: every request is self-contained and carries its own protocol version and capabilities" (MCP specification, architecture, revision 2026-07-28).

Three roles do the work. The host is the application. Each client "communicates with exactly one server", 1:1. Servers expose "resources, tools and prompts via MCP primitives".

The tool half is small. A client sends tools/list to discover what a server offers, then tools/call with a name and arguments to run one. A server that declared listChanged pushes notifications/tools/list_changed to clients that opened a subscriptions/listen stream, so a client learns of new tools without polling. Transports are stdio, newline-delimited messages over a client-launched subprocess, and Streamable HTTP, one POST per message to a single endpoint.

Look at what a tools/list response carries:

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

Set that next to a tool you would hand straight to the Messages API and the difference is inputSchema versus input_schema. Same name, same description, same JSON Schema. Not a coincidence, and it is why these two get confused.

Do MCP and function calling compete?

They compose, and the specification's own message flow says so. Discovery runs client to server (tools/list). Tool selection runs model to client. Invocation runs client to server (tools/call). The model sits outside the protocol at every step.

So an MCP client does five things in order: list the tools, translate them into the provider's tool format, let the model emit a tool call, translate it back into tools/call, return the result. Function calling is the model-side half of that loop, and MCP never covers it, because MCP does not speak to the model.

Which makes "MCP replaces function calling" backwards. MCP standardises where tools come from. Function calling is what happens next.

How do you choose? Five questions, in order

1. Do you own the tool code? If it lives in the same repo as your agent loop, a function-calling handler is enough. Stop here.
2. How many clients need this tool? One client you ship is the function-calling case. Two or more, or a client somebody else wrote, is the MCP case.
3. Is the tool set fixed at deploy time? A fixed list belongs in your request payload. A list that changes while the process runs is what notifications/tools/list_changed exists for.
4. Does the call cross a process or machine boundary? stdio and Streamable HTTP exist for that. If everything runs in one process, you are paying for a transport you do not need.
5. Do you want other people's agents to call your tool? The one question where MCP wins outright. Publish a server and any MCP client consumes it, no SDK per ecosystem.

Yes to 1 and no to the rest means write the loop.

When is MCP overhead?

Here is the case nobody writes down. A single-client agent whose tools live in its own repo does not need MCP, and adding one there gives you a second failure surface without removing the function-calling loop you still have to write.

What you take on: a subprocess or an HTTP endpoint, _meta version and capability fields on every request, a mandatory server/discover RPC to implement, and two error channels. The spec splits those deliberately: JSON-RPC protocol errors for an unknown tool or a malformed request, isError: true inside an otherwise successful result for execution failures. Your handler reads both. In exchange you standardised an interface with one consumer, which you wrote.

The token bill does not improve either. Anthropic's pricing section says tool use requests are priced on "The total number of input tokens sent to the model (including in the tools parameter)". MCP changes where a schema comes from, not whether the model reads it.

Which agent tools sit on which side?

Four of these six are recorded in this directory as MCP compatible. The other two reach tools through a function-calling API or their own SDK.

OpenAI Computer Use is the clearest example of the split. Its ecosystem value is the function-calling API itself, it is billed pay-as-you-go with no free tier, and MCP is not its integration path. Browserbase sits in that column for a different reason: it is infrastructure wired in through its own SDK or a framework's tool integration, free on the Hobby tier or $99/month for Startup (verified 2026-05-28).

Price does not separate the MCP side. LangChain is MIT-licensed and free to self-host, with LangSmith tracing at $39/month per seat (verified 2026-06-15). Claude Code is included with Claude Pro at $20/month (verified 2026-06-20). For the Copilot, Supervised and Fully Autonomous values in that first column, see AI agent autonomy levels.

What MCP does not fix

It does not decide anything. The spec calls tools model-controlled: the model chooses, exactly as it would without a protocol.

It does not make an agent safer on its own. The spec puts the guard on the client: "there SHOULD always be a human in the loop with the ability to deny tool invocations." Autonomy is a property of your approval policy, not of the wire format. The same server is Supervised under one client and Fully Autonomous under another.

Pick the protocol when you have more than one consumer. Pick the loop when you have one. If the answer came out as MCP, what is an MCP server and how it works covers the server side, and the four MCP-compatible clients above are the fastest way to test one.

FAQ

Is MCP a replacement for function calling? No. MCP is a wire protocol between a client and a tool server. Function calling is the model API feature that turns a prompt into a structured tool call. An MCP client hands its discovered tools to the model in the provider's own format, so both run in one loop.

Do MCP tools cost extra tokens? The definitions cost the same either way. Anthropic's tool use docs price a request on the total input tokens sent to the model, including the tools parameter. MCP changes where a schema comes from, not whether the model reads it. Forty tools on a server is forty schemas.

Can one agent connect to two MCP servers at once? Yes. Revision 2026-07-28 defines a client-host-server architecture where one host runs several clients, and each client communicates with exactly one server. The design also states servers cannot read the whole conversation or see into other servers, so isolation between them is intentional.

Do I need to write an MCP server for my own tools? Only if something other than your own application will call them. A tool in the same repo as your agent loop can be a plain function in your function-calling handler. Write a server when a client you did not build must discover and run it.

Does adding MCP make an agent more autonomous? No. The specification says tools are model-controlled but also that there should always be a human in the loop able to deny a tool invocation. Autonomy comes from your client's approval policy, not from the protocol. The same server behaves differently under two different clients.