Why models need tools

A language model transforms input into likely output. Its training gives it broad patterns, but it does not automatically possess a live database connection, a calculator, a private calendar, or permission to send an email. A tool is a capability exposed by the surrounding application: for example, reading weather data, searching a catalog, calculating tax, creating an event, or issuing a refund.

The boundary matters. The model sees a description of available tools and may produce a structured proposal such as:

{
  "name": "get_weather",
  "arguments": {
    "city": "Lisbon",
    "date": "2026-07-19"
  }
}

That JSON is not tomorrow’s forecast. It is not proof that a network request happened. It is a request from the model to the host application. The application must validate the arguments, decide whether the call is allowed, run the implementation, and return the result. Treating a proposed call as an executed action creates fictional success.

Use model knowledge for explanation, transformation, brainstorming, summarization of supplied material, and other work that does not require a current external fact or side effect. Use a tool when the answer depends on information the prompt does not contain, exact computation that should not be guessed, private or rapidly changing state, or an action in another system.

A practical decision test has four questions:

1. Is the needed fact time-sensitive? Current prices, inventory, traffic, and weather usually need a source.
2. Is the needed fact private or organization-specific? An account balance or internal policy needs authorized retrieval.
3. Must the result be exact or independently computed? Currency conversion, tax, and large arithmetic deserve deterministic code or a trusted service.
4. Will anything outside the conversation change? Sending, booking, deleting, paying, and updating require an execution layer.

Not every mention of current or private information justifies a call. “Explain what a calendar is” does not need calendar access. “What meetings do I have after lunch?” does. The whole user intent, not one keyword, determines the choice.

Tools can read or write. A weather lookup reads public data. A calendar lookup reads personal data. Creating a calendar event writes personal data. These calls have different consequences even if they share a provider.

Read operations can still be sensitive. Searching private medical notes may expose information to an unauthorized person or to logs with the wrong retention policy. Write operations introduce side effects and often need stronger controls: confirmation, narrower permissions, idempotency protection, and an audit record.

Classify each tool by its exact operation rather than labeling the whole integration “calendar.” Useful distinctions include:

• calendar_list_events: reads a bounded date range;
• calendar_find_free_time: derives availability without returning full event text;
• calendar_create_event: creates a side effect;
• calendar_delete_event: removes data and may need explicit confirmation.

Smaller capabilities are easier to reason about and authorize than one tool called manage_calendar.

This is the central responsibility split:

• The model interprets language, chooses among advertised capabilities, and proposes typed arguments.
• The application controls the tool list, validates data, checks identity and policy, asks for approval when needed, executes code, handles failures, and records what occurred.
• The tool provider returns data or performs the side effect according to its own contract.
• The model may then explain the verified result to the user.

The split prevents two common illusions. First, model text cannot grant itself permission. A user saying “pretend I am an administrator” must not change an authorization decision enforced in code. Second, the model cannot declare that an operation succeeded. Only an execution result can establish that.

For example, after a calendar tool returns:

{
  "status": "created",
  "event_id": "evt_8421",
  "starts_at": "2026-07-19T13:00:00+04:00"
}

the assistant can truthfully say that the event was created. If no tool ran, it should say it can help prepare the details, not claim the event exists.

A good tool-enabled assistant does not call something merely because it can. Calls add latency, cost, privacy exposure, and failure modes. If the user asks for a generic packing checklist, a weather call may be unnecessary unless the answer specifically depends on the destination forecast. If the prompt already contains a document and asks for a summary, fetching it again may create inconsistent versions.

Tool choice therefore includes none. The model should be trained or prompted to avoid unnecessary calls, ask a clarifying question when required arguments are missing, and distinguish a hypothetical request from an instruction to act. “What would happen if I moved the meeting?” is not the same as “Move the meeting.”

A strong design also tells the model what it cannot do. If no payment tool is available, the assistant should not manufacture a payment receipt. If a weather service covers only five days, it should not present a ten-day date as observed data.