Function calling is how tool use is wired up in practice. A language model can only produce text, so it cannot look up the weather or query a database by itself. Function calling gives it a structured way to ask: the model emits a machine-readable request naming a function and its arguments, and the surrounding application does the work.
The round trip
- Declare the functions. Alongside the conversation, you send a list of tools. Each has a name, a plain-language description of when to use it, and a JSON Schema describing its arguments.
- The model decides. On each turn it either answers directly or returns one or more calls, each with arguments filled in from the conversation.
- Your code executes. The application parses the arguments, runs the real function and captures the output.
- Return the result. The output goes back to the model, linked to the call it answers, and the model continues from there.
Providers name the pieces differently (OpenAI’s API returns a function call with a call_id; Anthropic’s returns a tool_use block and expects a tool_result), but the loop is the same. Both offer a strict mode that constrains the model’s arguments to match the schema exactly.
Why the description matters
The model chooses functions by reading their names and descriptions, so these are effectively part of the prompt. Vague descriptions lead to missed or wrong calls, and every tool definition also costs input tokens on each request.
From one call to an agent
Put this loop in a cycle, letting the model call tools until it decides it is done, and you have the core of an AI agent. Research such as Toolformer showed models could also learn when to call simple APIs, like a calculator or search engine, during generation. Because the model can request actions, applications should validate arguments and gate anything with side effects rather than executing calls blindly.