What is tool use?
Tool use is a language model’s ability to request that an external function be run, receive the result, and continue its work with that information. The model does not execute anything itself. It emits a structured request, usually a JSON object naming the tool and its arguments, and the platform runs the function and returns the output as a new message. At the API level the mechanism is called function calling.
A tool can be anything with a defined input and output: a SQL query against the warehouse database, a CRM lookup, a web search, a calculator, a ticket-creation endpoint, or another agent. Each tool is described to the model in a schema with its name, purpose, and parameters. The model chooses tools by reading those descriptions, so clear descriptions matter as much as clear prompts. The Model Context Protocol (MCP) is the common standard for publishing tools to models.
Why tool use matters
Tool use lets a model work with a company’s own data and systems. Without it, a model knows only what was in its training data and the prompt. With it, the model can look up the current price, check real inventory, read the actual contract, and write the result back. This also reduces hallucination, since the model can retrieve facts rather than recall them. Tool use is also where operational risk begins, because a tool that writes to a system of record turns a wrong answer into a wrong transaction.
Tool use in practice
A county permits office gives its resident-facing assistant four tools: look up a parcel by address, retrieve the zoning rules for a parcel, check the status of a permit application, and create a callback request for a planner. A resident asks whether they can build a detached workshop on their lot. The model calls the parcel lookup, then the zoning rules, reads the setback and size limits, and answers with the numbers for that property. If the resident wants to proceed, the model creates the callback request. It has no tool that approves permits, and that limit is enforced by the platform rather than by the prompt.
What to watch for
- Separate read tools from write tools, and require approval or a confirmation step on anything that changes a record.
- Write tool descriptions as carefully as prompts, since a vague description leads the model to call the wrong tool or skip it.
- Validate tool arguments in code before executing them; the model can produce a well-formed request with a wrong value.
- Log every tool call with its arguments and result so the audit trail covers actions as well as conversation.