Tools, function calling and MCP

A tool is a function that you describe to a language model. The model cannot run it. It replies with a structured request to call it, your code runs the function, and you send the result back. The Model Context Protocol (MCP) is an open standard for packaging tools as a server, so that any compatible AI application can use them without custom integration code.

Tools are what turn a model that writes text into an agent that does things.

The short version

• A tool definition is a name, a description and a JSON Schema for the inputs.
• The model asks, your code acts. That boundary is where you enforce every limit.
• “Tool use” and “function calling” are the same idea under different vendor names.
• MCP lets you reuse tools someone else has already built, or share yours across applications.

How a tool call works

The exchange has the same five steps with every provider. The field names below are Anthropic’s, from its page on how tool use works.

1. You send the user’s request together with a tools list.
2. The model replies with a stop_reason of "tool_use" and a tool_use block that holds an id, the tool’s name and an input object.
3. Your code runs the function with that input. The model is waiting and has done nothing yet.
4. You send back a tool_result block that carries the same id and the output.
5. The model continues. It either answers or asks for another tool, and the cycle repeats.

Step 3 is the part to remember. Because your code sits between the request and the action, it can check the input, ask a person, refuse, or log the call. The model has no way around it.

What a tool definition looks like

{
  "name": "read_note",
  "description": "Return the full text of one file in the notes folder. Use it after search_notes has returned a file name. It reads .txt files only and cannot read files in other folders.",
  "input_schema": {
    "type": "object",
    "properties": {
      "name": { "type": "string", "description": "A file name, e.g. standup.txt" }
    },
    "required": ["name"]
  }
}

The description is the most important line. The model chooses tools by reading descriptions, and it knows nothing else about your function. Anthropic’s guide to defining tools recommends that each one explain:

• what the tool does,
• when it should be used, and when it should not,
• what each parameter means,
• any important limits, such as what the tool does not return.

The same guide suggests grouping related operations into fewer tools, prefixing names with the service they belong to once you have several (for example github_list_prs), and returning only the fields the model needs for its next step.

Tool use and function calling are the same thing

Provider	Its name for the feature	Documentation
Anthropic	Tool use	Tool use overview
OpenAI	Function calling, “also known as tool calling”	Function calling guide
Google	Function calling	Function calling with the Gemini API

All three describe the same design: you declare functions with a schema, the model returns the name and arguments, and your application executes the call. The parameter names in the request differ, so copy the shapes from the provider’s own page instead of translating from another.

Where the tool runs

Anthropic’s documentation separates two kinds of tool by where the code executes:

• Client tools run in your application. These include every tool you define yourself. You handle the request and return the result.
• Server tools run on the provider’s infrastructure. Anthropic lists web search, web fetch and code execution among them. You switch them on in the request, and the results arrive in the response without your code running anything.

Server tools save work, and they also move the action outside your code, where you cannot inspect each call before it happens. For a first agent, tools you define yourself are easier to reason about.

When a tool fails

Do not let an exception end the run. Return a tool_result with is_error set to true and a message that says what went wrong and what to try next. “File not found. Call search_notes first to get a valid name” lets the model recover. “Error” does not.

A model may also ask for several tools in one reply. Run them all and return every result together in a single message, as the loop in Build an AI agent in Python does.

What the Model Context Protocol is

The MCP documentation defines it in one line: “MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems.” Anthropic published it on 25 November 2024, and the documentation now lists Claude, ChatGPT, Visual Studio Code and Cursor among the applications that support it.

Without MCP, every tool is a function inside one agent’s codebase. With MCP, the tools live in a separate program, an MCP server, and any application that speaks the protocol can discover and call them. The architecture overview names three roles:

Role	What it is
Host	The AI application the user works in. It manages the connections.
Client	A connector inside the host. There is one per server.
Server	A program that exposes capabilities to clients.

A server can expose three kinds of thing: tools (functions the model can invoke), resources (data the application can read for context) and prompts (reusable templates). The messages are JSON-RPC 2.0. A local server talks to its client over standard input and output, and a remote one uses HTTP.

In practice the host asks each server for its list of tools and hands them to the model as ordinary tool definitions. When the model requests one, the host routes the call to the right server. From the model’s side, an MCP tool and a hand-written tool look the same.

Tools or MCP: which to use

Situation	Use
One agent, a few functions that only it needs	Plain tool definitions in your code
A server already exists for the service you want	That MCP server
Several agents or applications need the same tools	An MCP server of your own
You want users to plug their own integrations into your application	MCP support in your application

You can mix them. The Claude Agent SDK and the OpenAI Agents SDK, both described in AI agent frameworks compared, each document MCP as a way to add tools alongside your own functions.

The security cost of a tool

Every tool widens what a mistaken or manipulated model can do. The MCP specification states it plainly: “Tools represent arbitrary code execution and must be treated with appropriate caution.” It also says that hosts must obtain explicit user consent before invoking any tool.

Two consequences follow for an agent builder:

• An MCP server from a third party is someone else’s code running with whatever access you give it. Read what it does and connect only the tools you need.
• Tool results are untrusted input. A web page or document that a tool returns can contain text written to steer your agent.

Both are covered in Testing and guardrails.

Frequently asked questions

What is function calling in an AI agent?

Function calling, also called tool use, is how a language model asks your program to do something. You describe a function to the model with a name, a description and a schema for its inputs. When the model wants it run, it replies with a structured request instead of text. Your code runs the function and sends the result back.

Does the AI model run the tool itself?

Not for tools you define. The model only produces a request that names the tool and gives its inputs. Your application decides whether to run it, runs it, and returns the output. Some providers also offer hosted tools, such as web search, that run on the provider's own servers.

What is the Model Context Protocol (MCP)?

MCP is an open standard for connecting AI applications to external systems. A service publishes its capabilities once as an MCP server, and any compatible application can connect to it and offer those capabilities to a model as tools. Anthropic introduced it in November 2024.

Do I need MCP to build an AI agent?

No. An agent needs tools, and you can define those directly in your own code. MCP is worth using when a server already exists for the system you want to reach, or when you want several applications to share the same tools.

How many tools should an AI agent have?

As few as the job needs. Every tool adds text the model must read on each request and one more option it can choose wrongly. Anthropic's guidance is to consolidate related operations into fewer, more capable tools and to give each a detailed description.