dful.
Dful Dark
Theme
Knowledge tree
On this page

Tool Use

How a model requests a tool, who performs the operation, and what result returns to the next step.
Updated 28 Aug 2026

A tool is a function or capability that a model can ask to run. The model generates the call; the harness or application performs the operation; the result returns to the model.

How a tool call runs The model requests a tool with arguments. The harness validates and executes the operation, then returns the result to the model. Harness / runtime Model request Tool name + arguments Validate Arguments + permission Run the operation Execute outside the model File, shell, or API The target environment Result Information for the next turn return result How a tool call runs The model requests a tool with arguments. The harness validates and executes the operation, then returns the result to the model. Model request Tool name + arguments Harness / runtime Validate Arguments + permission Run the operation Execute outside the model File, shell, or API The target environment Result Information for the next turn return result
Figure 1. The model requests an operation, the harness validates and runs it, and the result returns to the next turn.

Definition

A tool normally has a name, description, and parameter schema. The name identifies the operation. The description says what it is for. The schema defines the arguments the model can generate and makes validation possible before execution.

{
  "name": "read_file",
  "description": "Read a range of lines from a text file",
  "parameters": {
    "type": "object",
    "properties": {
      "path": { "type": "string" },
      "start_line": { "type": "integer" }
    },
    "required": ["path"]
  }
}

A vague description makes selection harder. If a tool deletes data, sends a message, or has an important precondition, its interface should make that clear.

Tool call and execution

Suppose the model needs to inspect src/app.ts. It emits a read_file call with that path. The runtime validates the arguments, reads the file, and returns the requested lines. The model then decides whether to read more, make a change, or answer.

The model did not open the file directly. It produced structured output that another program turned into a real action.

Before execution, the harness can check that arguments match the schema and that the operation is allowed. A syntactically valid call can still target a path outside scope or request an action that needs approval.

Results

The result should contain what the model needs for the next decision. Shell text and stable JSON fields can both be appropriate; every result does not need the same representation.

Size matters because the result may enter the next inference. A file-reading tool with line ranges is easier to use than one that always returns the complete file. For a large log, the runtime can preserve the source and return only matches or a relevant region.

Errors should also be explicit. If the file does not exist, that failure lets the model correct the path. Hiding it inside success-shaped output only makes the next step worse.

Side effects and retries

Repeating read_file is normally safe. Repeating send_message after a timeout can send the same message twice, while a repeated delete_file may encounter state changed by the first call.

Tools that modify the environment therefore need more care: permissions, confirmation, or a way to check whether the effect already happened. The harness enforces those decisions, while the tool definition should make the possible effect understandable.

Model APIs covers how tool definitions and calls appear on the wire. Agent Loop covers how the result drives the next decision.

References