Tool calling (function calling)
Tool calling, also called function calling, lets a language model request an action from the application around it. The developer declares the available tools with a name, a description and a schema of parameters; the model replies with a structured request to call one of them, the application executes it and sends the result back. The model never runs code itself: your system decides whether and how the call happens.
Why it matters for a PM
Tool calling is what turns a text generator into a feature that looks up an order, books a slot or updates a CRM record. For a PM, each tool is a small product contract: what it does, what it must never do, which errors it returns and who is allowed to trigger it. Vague tool definitions are a frequent reason why agents pick the wrong action.
Example
A delivery app exposes a tool named get_order_status that takes an order number. When a customer asks where their package is, the model calls the tool, the app queries the logistics system and returns the status, and the model phrases the answer. Changing the address goes through a separate tool that asks for confirmation.
Key points
- The model chooses a tool from its description, so the description is part of the specification.
- Parameters follow a JSON schema; the application still validates them before acting.
- Tools with side effects need idempotency so that a retried call does not charge or email twice.
- Errors go back to the model in plain words it can act on, not as silent failures.
- Permissions belong to the application layer, never to the prompt alone.
Common mistakes
- Exposing one generic tool (“run any query”) instead of narrow, purpose-built ones.
- Letting the model trigger high-impact write actions without confirmation.
- Writing tool descriptions for developers rather than for the model that must choose between them.
- Treating tool output as trusted, although it may contain injected instructions.
Go further with Module
The courses and lessons that cover this concept: