AI & Development
Function calling lets LLMs call external APIs, read databases, and trigger actions in your system.
Function calling - also referred to as tool use - is a feature of modern language models that allows the model to request the execution of external functions rather than generating a text response. Instead of trying to answer "what is the current weather in Paris?" from training data, a model with access to a weather tool generates a structured request to call that tool, receives the result, and then incorporates the result into its response. This pattern is what makes LLM agents practically useful rather than purely conversational.
You provide the model with a list of available tools, each described with a name, a description, and a JSON Schema for its parameters. When the model determines that answering the user's request requires one of those tools, instead of generating a text response, it generates a structured tool call - a JSON object specifying which tool to call and with what arguments.
Your application code receives this tool call, executes the corresponding function with the provided arguments, and returns the result back to the model as a tool result message. The model then continues the conversation with the new information. This exchange can happen multiple times in a single conversation turn if the model determines it needs to call multiple tools.
The most common failure mode in function calling applications is poorly designed tool definitions. The model decides which tool to call and what arguments to pass based on the descriptions you provide. Vague descriptions produce wrong tool selections. Missing parameter descriptions produce incorrectly formed arguments.
Good tool descriptions follow these principles: they describe what the tool does, not how it does it; they specify what the result will be; they note any important constraints (rate limits, data freshness, side effects). For parameters, each field should have a clear description of what it means and its expected format. A date parameter described as "date" is ambiguous. "date: The calendar date to query, in ISO 8601 format (YYYY-MM-DD)" is not.
Models can be configured to always call a tool ("tool_choice: required") or to optionally call tools as needed ("tool_choice: auto"). The "required" setting is useful for extraction and classification tasks where you always want structured output - the tool definition enforces a JSON schema, and the model always generates a valid structured response rather than free text. The "auto" setting is appropriate for conversational agents where tool use is conditional on the user's request.
Tool choice can also be forced to a specific tool ("call get_weather") when you know exactly which tool the current step requires. This is common in multi-step agentic workflows where each step has a predefined function to call.
Modern models support parallel tool calling - generating multiple tool call requests in a single response rather than calling tools sequentially. If a user asks "what is the weather in Paris and Tokyo?", a model with parallel tool use will generate two simultaneous weather tool calls rather than calling the first, waiting for the result, then calling the second. For workflows with multiple independent data lookups, parallel tool calls can significantly reduce total latency.
Supporting parallel tool calls in your application means handling multiple tool calls from a single model response and returning all results before the model continues. The implementation is straightforward but requires careful testing - the model may generate parallel calls for operations that are not safe to run simultaneously (for example, two writes to the same database record).
Tool use that has side effects - sending emails, modifying database records, placing orders, posting to APIs - requires careful design. The model makes tool calling decisions based on its interpretation of the user's intent, and that interpretation is not always correct. A model that can send emails on behalf of a user can send the wrong email to the wrong recipient if the tool is poorly specified or if the user's request is ambiguous.
The standard mitigation is a human-in-the-loop step for consequential actions: the model proposes an action, your UI shows the user what will happen and asks for confirmation before executing. This is the same pattern that well-designed AI coding tools use for file edits and git operations. For lower-stakes actions, automatic execution is appropriate. For irreversible or high-impact actions, confirmation is worth the friction.
Tool calls fail. Network errors, API rate limits, invalid inputs, and unexpected data formats all cause tool failures. A well-designed tool use system handles these failures gracefully: the tool returns a structured error result, the model acknowledges the failure in its response, and the application has a defined fallback path. Models handle tool errors well when the error format is informative - "Rate limit exceeded: retry in 30 seconds" is more useful than "Error: 429" for the model to communicate to the user or to decide whether to retry.