Tool calling

How tool calling works

Tool calling is a conversation between the application and the model. OpenAI documents five steps for the loop 1. The application sends a prompt plus a list of tools. Each tool has a name, a description and a JSON Schema for its arguments 1. The model may reply with ordinary text, or with one or more tool calls that name a function and fill its arguments 1.

The application then runs the matching code. It must not skip this step. The Thoughtworks guide notes that the model generates a structured proposal, and the program is responsible for invoking the function and capturing the result 2. The app appends the tool output to the conversation and calls the model again 1. The model may answer, or it may issue another tool call. That loop continues until the model returns a final reply the user can read.

Model Context Protocol standardizes the same loop across hosts. An MCP client asks an MCP server for its tools with tools/list, then runs one with tools/call 3. The host still owns execution. The specification expects a person to be able to deny a tool invocation before it runs 3. That human gate matters once tools can send mail, move money or write CRM records.

Hosts can constrain the loop further. OpenAI's tool_choice setting can leave the decision to the model, require a tool call or force a named function 1. Parallel tool calls let the model request several functions in one turn, and hosts can disable that when order matters 1. Strict mode can force arguments to match the schema, which cuts malformed calls before they hit production code 1.

Cost sits on both sides of the wire. Declared tools consume context tokens every turn they stay in the prompt 1. Each successful data tool may also bill credits on the server that runs it. A short catalog with clear cost text in the description helps the model pick the cheaper path when two tools overlap.

Tool calling vs function calling

Vendors use both phrases for the same pattern. OpenAI's guide opens by saying function calling is also known as tool calling, and it describes functions as one kind of tool defined by a JSON Schema 1. Built-in tools such as web search sit beside those functions on the same request 1. The words change. The loop does not.

MCP drops the word function and talks only about tools. A tool still has a name, a description and an inputSchema, and the client runs it with tools/call 3. In practice that split is packaging, not capability. An API that lists functions and an MCP server that lists tools both feed the model a catalog of callable operations with structured inputs.

The design work sits in that catalog. Clear names, short descriptions that state when to use the tool and what it costs, and strict argument schemas reduce wrong picks 1 3. A long list of overlapping tools makes the model guess, and each wrong guess can spend money or change a system the team did not intend to touch. OpenAI's own guidance is to keep the number of initially available functions small and to defer rarely used tools when the surface grows 1.

Security rules apply on both sides. The application should show tool inputs before sensitive calls, set timeouts and log usage 3. Servers should validate arguments, rate limit calls and sanitize outputs 3. Tool calling without those controls is a remote code path with a friendly name.

Example of a tool call loop

OpenAI's function calling guide walks through a get_horoscope tool 1. The application declares a function with a sign argument. The user asks for an Aquarius horoscope. The model returns a function_call that names get_horoscope and sets sign to Aquarius 1. The application runs its local getHoroscope code, appends a function_call_output and calls the model again 1. The second response is the text the user reads. Nothing in that flow required the model to execute Python itself.

An MCP call follows the same shape with different method names. After tools/list, the client sends tools/call with a tool name and arguments, and the server returns a content array plus an isError flag 3. If the tool does not exist, the server returns a protocol error. If the tool exists but the input is wrong, the result can set isError so the model can correct the next attempt 3.

A data tool adds a bill. RichAPI's MCP server exposes the same lookups as its REST API behind OAuth 4. An agent that needs a work email can call the email finder tool. On that waterfall endpoint a miss settles at zero credits, so a retry path does not burn the budget on empty records 4. A phone finder miss follows the same rule, which keeps list-scale agents from paying for silence 4.

Tool calling vs MCP tool

Tool calling is the loop. An MCP tool is one item the loop can pick. OpenAI describes the five-step conversation between app and model 1. MCP defines each callable entry as a tool with a name, description and inputSchema 3. Use tool calling when explaining the pattern. Use MCP tool when naming a specific server function.