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?

That last question has a new answer since 2026: a judgement over the result — does this output contain an instruction aimed at the model? — is now cheap enough to ask every time. It is also cheap enough to be fooled by the result it is judging, which is why the state an admission gate reads is assembled by the harness and never by the tool whose call is being judged. The orchestration sheet has the order of gates.

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.