How AI Agents Actually Use Tools: Function Calling and MCP

An agent that books a meeting, looks up an order, or edits a file looks like it is reaching into the world. Under the surface, nothing of the sort happens inside the model. The model never runs code, never touches a file, never calls an API. What it does is far narrower and far more powerful: it returns a structured request that names a function and fills in its arguments, and the software around it executes that request and hands the result back. Everything an agent does with tools, from a single web search to a fifty-step research run, is repetitions of this exchange. This guide explains the mechanics from the ground up: how a tool is defined, the loop that executes calls, where execution happens, and the open standard, MCP, that is replacing hand-built integrations one server at a time.

What tool use actually is

Every major provider describes the same underlying mechanism with slightly different names. OpenAI calls it function calling, also known as tool calling. Anthropic calls it tool use, also called function calling. Google calls it function calling for the Gemini API. The mechanism is identical in all three: you describe functions to the model in a structured schema, the model decides during generation that one of them is needed, and it returns a special response containing the function name and the arguments it chose. Your application executes the real work, formats the outcome, and sends it back to the model, which continues from there. The model plans and fills in blanks; your code does things.

This split is the whole trick. Language models are trained on text, and they are good at mapping a request like 'what is the weather in Paris' to the idea of a weather lookup with a location argument. They are not authorized to run your database, hold your credentials, or decide which side effects are safe. Tool use keeps the model on the planning side of that line and puts your code on the execution side. You get the model's flexibility in deciding what to do without giving it the ability to do it unsupervised.

Three observations from the provider documentation shape everything that follows. First, the description you write for each tool is the steering wheel: Claude decides whether to call a tool based on the user's request and the tool's description, and OpenAI's best-practice guidance starts with clear, detailed function names and parameter descriptions. Second, tool definitions cost tokens: they are injected into the request (Anthropic adds a special system prompt for tool use; OpenAI injects function definitions into the system message), so a large tool surface has a standing cost on every call. Third, the model does not decide alone whether calling is allowed at all: all three providers let you constrain tool behavior, from Anthropic's tool_choice settings to approval patterns you build yourself.

The anatomy of a tool definition

A tool definition has four parts, and each one does a distinct job. The name is the handle the model reaches for; it should say exactly what the tool does. The description tells the model when to use the tool, what each argument means, and what the output represents; this is the part that most determines whether calls are accurate. The parameters field is a JSON Schema describing the arguments the model may fill in: types, which fields are required, and constraints like enums or value ranges. An optional strictness flag (OpenAI's strict mode) tightens enforcement so the model must produce arguments that match the schema exactly.

Here is a complete, working-shape example. It follows the schema layout documented by OpenAI for function tools, which Anthropic's input_schema and Gemini's function declarations mirror in structure: name, description, and parameters written as JSON Schema.

{
  "type": "function",
  "name": "search_articles",
  "description": "Searches the site's article archive by keyword. Returns matching article titles, URLs, and one-paragraph summaries. Use when the user asks for information that published articles may already cover.",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "Keywords to search for, for example 'tax filing deadlines'."
      },
      "limit": {
        "type": "integer",
        "description": "Maximum number of results to return. Defaults to 5.",
        "minimum": 1,
        "maximum": 20
      }
    },
    "required": ["query"],
    "additionalProperties": false
  },
  "strict": true
}

Read it the way the model does. The description says what the tool is for and when to reach for it, which is how the model distinguishes it from a web search tool or a database query tool. The properties tell the model what it may fill in and what each value means; the limit parameter documents its own default and range so the model does not have to guess. The required list marks query as mandatory, and additionalProperties: false with strict mode closes the door on invented extra fields. Every one of these details is load-bearing: OpenAI's guidance explicitly recommends using enums and object structure to make invalid states unrepresentable, and describes the 'intern test', where if a human given only the schema could not use the function correctly, the schema needs the answers to the questions they would ask.

The description also carries behavioral instructions that are not part of the schema at all. 'Use when the user asks for information that published articles may already cover' is a triggering rule, and 'returns one-paragraph summaries' tells the model what shape to expect back. OpenAI recommends using the system prompt to describe when (and when not) to use each function, with exact instructions rather than hints. The schema defines what the model may do; the prose defines when it should.

The tool-use loop, step by step

A single tool call is a five-step round trip, documented in nearly identical terms by OpenAI and Anthropic. OpenAI's function-calling guide lists the flow explicitly; Anthropic's tool-use documentation walks the same round trip with its own block names. Here it is in one place:

• 1. Your application sends a request to the model: the conversation so far plus the list of tool definitions.
• 2. The model reasons over the request and decides a tool is needed. It returns a structured call naming the tool and its arguments. In Anthropic's API this arrives as one or more tool_use blocks with a stop_reason of tool_use; in OpenAI's it arrives as function_call items with a call_id.
• 3. Your code executes the call. It validates the arguments, runs the real function (a database query, an API request, a file read), and captures the outcome.
• 4. Your application sends a second request to the model containing the original context, the model's call, and the tool's output (Anthropic's tool_result block, OpenAI's function_call_output referencing the call_id).
• 5. The model observes the result and either calls another tool or produces the final answer.

Watch it happen once and the loop becomes concrete. A user asks for the cheapest flight option next Friday. The model has a search_flights tool, so it returns a call with origin, destination, and date filled in. Your code runs the airline query, returns three options, and the model sees prices it never had in its training data. It might call a second tool, get_calendar, to check for conflicts, then answer with the cheapest conflict-free option. Each iteration adds one verified fact to the conversation, and the model decides after every observation whether it has enough to answer. The loop ends when the model responds with text instead of a tool call.

Two details matter in production. First, the loop is unbounded by default: a confused model can call tools in circles, which is why runs need step budgets and why results should be validated before re-entering the context. Second, the model may return several calls at once. Anthropic documents parallel tool use explicitly, and OpenAI notes that responses can include zero, one, or multiple calls, advising that applications handle all three. Your executor must therefore be written as a dispatcher over a list of calls, not a handler for a single one.

You do not always have to write this loop by hand. Anthropic's SDKs include a Tool Runner that executes your tools and feeds results back automatically, and agent frameworks package the same orchestration with retry and state management. The loop is the same either way; the only question is whether you own the code around it or a library does.

Who executes the call: your code or the provider

Anthropic draws the clearest line in the industry between where tool code runs, and it is worth learning because it generalizes. Client tools run in your application. That includes tools you define yourself and tools for which Anthropic publishes the schema and trains the model, such as the bash, text editor, and computer-use tools. The pattern is always the same: the model returns tool_use blocks, your code executes the operation, and you send back tool_result. Server tools run on Anthropic's infrastructure with no handler code in your application: web search, web fetch, code execution in a sandboxed container, and tool search, which discovers and loads from thousands of tools on demand.

The distinction decides who owns the hard parts. With client tools you own execution, credentials, timeouts, retries, and sandboxing; you also get full control over what the tool can touch. With server tools the provider owns execution and you accept their sandbox and their pricing: server tools can carry usage-based charges on top of tokens, and Anthropic's pricing notes spell out that tool definitions, tool_use blocks, and tool_result blocks all consume tokens. Neither choice is categorically better. Read-only lookups against your own data belong in your code; generic capabilities like web search belong with the provider.

One more Anthropic concept deserves a place here because it quietly shapes agent behavior: tool_choice. With the default auto setting the model decides each turn whether to call a tool or answer directly, calling when the request maps to a tool's described capability and the answer is not already in context. You can force a call or forbid calls entirely. Prompting can nudge the boundary, but tool_choice enforces it, which matters when a tool has side effects you only want under explicit conditions.

MCP: one standard instead of many integrations

Before MCP, every agent product integrated with every external system by hand: a custom Slack connector here, a bespoke database wrapper there, each one a snowflake of authentication, schema translation, and error handling. The Model Context Protocol is the industry's answer, an open-source standard for connecting AI applications to external systems, maintained with broad ecosystem support across assistants, editors, and developer tools. The project's own analogy is apt: MCP is a USB-C port for AI applications, a standardized way to plug capabilities in instead of wiring each one from scratch.

The architecture has three participants. The MCP host is the AI application the user interacts with, such as an editor or desktop assistant. The host creates one MCP client per server it connects to; each client maintains a dedicated connection to its server. The MCP server is the program that provides context: it can run locally on the same machine or remotely over the network. A concrete picture: an editor acting as host opens a client to a Sentry server for error data and a second client to a filesystem server for local files, and both look identical to the model behind them.

Underneath, MCP separates two layers. The data layer is a JSON-RPC 2.0 protocol defining the message structure and semantics: capability and version discovery, the core primitives, and notifications. The transport layer moves those messages and handles connection setup, framing, and authentication. There are two transports. Stdio runs the server as a local subprocess communicating over standard input and output, with no network overhead. Streamable HTTP runs the server remotely over HTTP POST with optional Server-Sent Events streaming, and supports standard HTTP authentication including bearer tokens and API keys, with OAuth recommended for obtaining tokens.

Servers expose three primitives. Tools are executable functions the model can invoke: file operations, API calls, database queries. Resources are data sources that provide context without executing anything: file contents, database records, API responses. Prompts are reusable templates that structure interactions, such as system prompts or few-shot examples. Clients discover what a server offers through list methods (tools/list is the first one that matters), then execute with tools/call. That discovery step is what makes MCP dynamic: the tool surface can change at runtime, and the client learns about it through the protocol instead of a code change.

Where this meets the providers: Anthropic's API includes an MCP connector that lets the model reach remote MCP servers directly from the Messages API without a separate client in your code, and OpenAI lists MCP server access among its built-in tools. The direction is unmistakable: the proprietary integration you write today becomes the standard server you configure tomorrow.

What an MCP server configuration looks like

Configuring a server is mostly telling the host how to reach it and what credentials to present. A local server needs a command to launch, arguments, and environment variables. A remote server needs a URL and an authentication header. The shape below is illustrative rather than any single client's official schema, but every major host's configuration is a variation on these fields:

{
  "mcpServers": {
    "docs-search": {
      "command": "npx",
      "args": ["-y", "docs-search-mcp"],
      "env": { "SEARCH_API_KEY": "sk-..." }
    },
    "team-calendar": {
      "url": "https://calendar.example.com/mcp",
      "headers": { "Authorization": "Bearer <oauth-token>" }
    }
  }
}

Two things in that example deserve attention from anyone building agents. First, the env block carries a live secret. Environment variables are the standard way servers receive credentials, and MCP's own logging guidance warns against emitting credentials through log channels, which means your harness must redact them from logs, error messages, and anything the model might quote back. Second, the remote entry shows bearer authentication, which is the simple case; for anything user-facing, MCP recommends OAuth so the server gets a scoped token for the actual user rather than a shared key. A server configured with one shared credential acts as every user at once, which is fine for a personal setup and a liability the moment more than one person is involved.

The security model: scopes, gates, and sandboxes

Tool calling concentrates risk in one place: a system that turns model output into executed actions. The defenses are layered, and each layer answers a different question.

• Least-privilege scopes: give each tool the narrowest credential that lets it do its job. A read-only search tool gets a read-only key; a deployment tool gets nothing until a human approves. Anthropic's own execution split is the model to copy: the code that runs decides the blast radius, so scope the credential to the tool, not the agent.
• Approval gates before irreversible calls: sort tools into auto-run, ask-first, and never-autonomous by what a bad call costs. Sends, deletes, purchases, and permission changes sit behind a human decision; reads and reversible drafts run free. The gate must show the actual arguments, not just the tool name, or the approver is decoration.
• Sandboxing for executed code: when a tool runs code, it runs in a container with bounded filesystem, network, and time. Anthropic's code execution tool runs in a sandboxed container for exactly this reason; your own code-running tools deserve the same treatment.
• Result validation before re-entry: validate a tool result's shape before it enters the model's context, and turn empty or malformed results into errors the model must react to rather than citable data. A result the model cannot trust is worse than no result, because the model will cite it anyway.
• Credential hygiene in the loop: tool arguments, results, and logs must never carry secrets. Redact keys from anything the model sees, because anything the model sees can end up quoted in an answer, a ticket, or a log file.

Two deeper treatments on this site go further than this overview can. The permissions guide works through blast-radius thinking, permission tiers, and chained-tool transitive permissions in detail, and the security guide covers prompt injection, the headline risk for any agent that reads untrusted content through its tools. Read those before connecting an agent to anything that holds other people's data.

How tool calling fails

Tool calls fail in a small number of recognizable ways, and each one points at a different layer of the system. Schema mismatch is the most common: the model fills in an argument the schema did not allow, omits a required field, or invents a parameter name that sounds right. The fix is validation before execution, with rejections worded so the model can correct itself, plus schemas tightened with enums and required fields until the invalid states are unrepresentable.

Hallucinated calls are the stranger cousin: the model invokes a tool that does not exist, or calls a real tool with arguments that describe something the tool cannot do. This usually means the tool surface is too large or the descriptions too vague; the model is guessing at capabilities from names. OpenAI's guidance to keep the initially available function count small (under twenty is the documented rule of thumb) and to defer rarely used tools with tool search is aimed squarely at this failure. When the model cannot see thirty tools at once, it stops inventing the thirty-first.

Result failures are quieter and more dangerous. A tool returns an empty result that looks like success, a malformed payload, or data in units the model misreads, and the model builds its answer on top of it. The discipline is the same as in the security section: validate shapes, require provenance, and make the model say what it actually observed rather than what it expected. The failure-diagnosis guide on this site walks through these cases as worked examples, including the polite empty result and the run that forgets the question, with the layer each failure lives in.

Cost failures deserve their own mention because they arrive as a bill, not an error. Tool definitions consume input tokens on every request, tool results consume context, and server-side tools can add usage charges. A run that loops through a dozen tools is paying for the schema of all of them on every turn plus the full text of every result. Budgeting per tool, capping result sizes, and clearing stale results from context are the levers; the cost guide on this site models them end to end.

Build a tool, use MCP, or use a built-in: the decision

Most teams reach the same question from three directions: should we write a custom integration, configure an MCP server, or rely on the provider's built-in tools? The answer falls out of who owns the capability and how standard the need is.

• Use a built-in tool when the capability is generic and the provider runs it well: web search, web fetch, sandboxed code execution. You trade control for zero maintenance, and you accept the provider's sandbox and pricing.
• Use an MCP server when the capability is standard but the data is yours: databases, calendars, ticket systems, file stores. If a maintained server exists for your system, configuring it beats writing and securing your own integration, and you inherit the ecosystem's auth and discovery work.
• Build a custom tool when the capability is specific to your business logic: pricing rules, internal workflows, proprietary scoring. This is also the right choice when you need execution guarantees no standard server offers, like transactions or custom approval flows. Write the schema as carefully as the code; the schema is the user interface the model sees.
• Mix them deliberately. A typical production agent uses built-in search, MCP servers for company systems, and a handful of custom tools for the logic that makes the business the business. The loop does not care where a tool came from; your security review should.

One caution that applies to all four choices: the tool surface is a user interface, and it deserves the same design care. OpenAI's 'intern test' is the bar: a competent human given only your tool definitions should be able to use them correctly. If they cannot, the model will not either, and no amount of prompt engineering compensates for a confusing interface. Name tools as verbs, describe arguments with examples and formats, document what the output represents, and combine functions that are always called in sequence so the model has fewer ways to get the choreography wrong.

Sources and further reading

• Anthropic, 'Tool use with Claude' (docs.anthropic.com/en/docs/build-with-claude/tool-use): client vs server tools, the tool_use/tool_result round trip, tool_choice, the SDK Tool Runner, and token pricing for tool use.
• OpenAI, 'Function calling' (platform.openai.com/docs/guides/function-calling): the five-step tool-calling flow, the function definition schema (type, name, description, parameters, strict), best practices for defining functions, and token usage.
• Google, 'Function calling with the Gemini API' (ai.google.dev/gemini-api/docs/function-calling): the three use cases (take actions, augment knowledge, extend capabilities) and function declaration structure.
• Model Context Protocol, 'What is MCP?' and 'Architecture overview' (modelcontextprotocol.io): the host/client/server participants, the JSON-RPC 2.0 data layer, stdio and Streamable HTTP transports, the tools/resources/prompts primitives, and OAuth for remote authentication.