Tool use / function calling

A structured interface through which a model requests a named operation with arguments and receives the operation's result as new context.

With tool use, a model can return a request such as `send_email` with a recipient and subject instead of returning only prose. A runtime decides whether that tool is available, validates the arguments, applies permissions, executes the operation, and supplies the result to the next model turn. Tools can read data, run code, edit files, or change an external system. Some products hide this runtime behind an agent interface, but the separation still matters: a model request is not proof that the requested action is valid or authorized.

Builder example

Tool boundaries are where generated intent becomes system behavior. Each tool should expose the smallest useful operation, accept a typed argument shape, use credentials scoped to the job, and return errors the workflow can handle. Record material calls and results with enough context to diagnose them. A summarization workflow generally needs read access; it should receive a send capability only when sending is part of its tested contract.

The user says, 'Book Sarah for Tuesday afternoon.' The model proposes a calendar-create call with attendee, time, title, and timezone.

Validate the fields, confirm ambiguity, and require approval before sending invites.

Common confusion: Function calling usually means the model emits a structured request and a separate runtime executes it. A hosted code interpreter or computer-use product may make execution feel native to the model, but an application environment still supplies and governs the capability.