Function calling lets a model request real actions instead of just describing them.
ConceptWhat it is
Tool calling, also called function calling, is a model capability where the LLM outputs a structured request to invoke a named function with specific arguments, rather than only generating free text.
It exists because language alone cannot fetch live data, run calculations, or change external systems; giving the model a defined schema of callable tools lets it bridge from reasoning to real-world action reliably.
How it worksThe mechanics
The application declares available functions with names, descriptions, and JSON-schema parameters; the model, given a user request, decides whether a tool is needed and returns a structured call with arguments, which the application executes and feeds the result back to the model to continue the conversation.
At a glanceSee it
Tool calling is grounded before runtime — the model can only choose among the named schemas a developer registered into its context, and it picks by matching descriptions to intent.
The base loop's single validate step unfolds into three distinct failure gates — unknown name, bad arguments, failed execution — each fed back to the model as a correctable error.
When to use itWhere it fits
- Needing the model to fetch live data like weather, prices, or account details.
- Automating actions such as booking, sending, or updating records.
- Enforcing structured output by modeling it as a function call schema.
- Building any agent that must interact with APIs or databases.
When NOT to use itLimits & anti-patterns
- Pure text generation tasks with no external system to touch.
- Extremely latency-sensitive responses, where each tool round-trip adds delay.
- Untrusted inputs where a malicious user could manipulate arguments into unsafe calls without strict validation.
Trade-offsAdvantages & costs
Advantages
- Gives models reliable access to real-time and proprietary data.
- Structured schemas reduce parsing errors compared to free-text extraction.
- Composable building block for larger agent architectures.
- Supported natively by most major model providers today.
Trade-offs & costs
- Each tool call adds latency and cost from an extra model round-trip.
- Models can hallucinate arguments or call the wrong tool.
- Requires careful schema design and validation to be safe.
- Debugging chains of tool calls can be harder than single completions.
ExampleIn the real world
A travel-booking assistant uses function calling so the model can invoke a flight-search API with structured origin, destination, and date arguments, then present real fare results instead of guessing prices.
ToolsHow to implement it
- OpenAI function callingnative structured tool-call support in the Chat Completions API.
- Anthropic tool useClaude's equivalent structured tool-invocation format.
- Pydanticvalidates and types function arguments before execution.
- JSON Schemastandard format for describing callable function signatures.
Cost & effortWhat it takes
Adds one extra model call per tool invocation on top of normal token costs; latency scales with number of round-trips. Engineering effort is low for a single tool, moderate as the tool catalog grows.
What changedWhat changed here
Updated this page Agentic features are reaching mobile surfaces, so an agent's integration target can be a phone app rather than a desktop or API.
Updated this page Platform terms, not just technical capability, can block an agent from completing a purchase on a user's behalf, so agent checkout flows need per-site permission rather than assumed open access.
Updated this page Google opened early access to an MCP server for Google Home, letting agents control devices and query activity, which is a concrete example of a platform exposing a tool surface to third-party agents.
Three kinds of claim, strongest first. Signal runs every morning.