Tool Interfaces

Tools give the model a way to act. This is the moment the agent stops being a talker: instead of describing the work, it requests it — as a structured action the harness can execute.

The contract

A tool has a name, a description, and a schema for its arguments — sometimes an output schema too. The model's side of the contract is a decision: "I should call this tool, with these arguments." The harness's side is everything after that.

{
  "name": "run_tests",
  "description": "Run the project test suite, optionally scoped to a path",
  "input_schema": {
    "type": "object",
    "properties": {
      "path": { "type": "string", "description": "Test file or directory" },
      "watch": { "type": "boolean", "default": false }
    }
  }
}

That schema is doing real harness work. It constrains what the model can express, catches malformed requests before they execute, and gives the description — which is really a tiny instruction — a place to teach the model when this tool is appropriate.

In the wild

You're using this primitive whenever you touch:

• Function calling / tool use — the raw API mechanism from every model provider
• MCP (Model Context Protocol) — a standard way for any service to expose its tools to any agent; the reason the ecosystem exploded
• The built-ins — bash, grep, find, file read/write in coding agents

Choosing an action is not the same as performing it safely

Say the model correctly decides: run the test command. Immediately, harder questions appear — and none of them are the model's to answer:

• Where? On your laptop? In a container? A cloud sandbox?
• With what? Network access? Secrets? Write access to the whole repo?
• And the output — tools fail, return messy text, or partial data. Web pages can carry prompt injection. How much do we trust what comes back?

The model chose a valid tool with valid arguments — but the operational question of where this runs and under what boundaries belongs to a different layer entirely.