A tool is one capability the agent’s LLM can call while it is talking to someone: look an order up, book a slot, write a lead into your CRM. You define what the model sees — a name, a description, an argument schema — and an ordered list of operations that runs when it is called. Tools belong to the workspace, not to an agent. One tool can be attached to several agents, and it carries its own draft and published versions.

The fields

name, description and json_schema are the three fields that decide whether the model calls the tool correctly, and they are worth more care than the tree — see schema and description. The tree itself is covered in the operation tree.

The behaviour flags

long_running_task — on voice and video, the tree is detached the moment the model calls it: the model is handed “Sure — let me take care of that. One moment.” and keeps talking to the caller while the work runs. When the tree finishes with a result, the agent is asked to share it. Text agents wait for the result either way — a text session is scoped to one message, so detaching would drop the answer. A tool containing a transfer cannot be long_running_task; publish refuses it. silent — the model is told nothing after the tool runs, so it does not speak on top of it. You rarely need to set it: a tool in which no operation can return a response is silent automatically, and so is any run that reaches end_call. Setting it is for the case where the tree does have an http or code result and you do not want the model narrating it. disable_interruptions — the caller cannot barge in while the tool runs. Reach for it when a tool runs long enough that a caller will say “hello?” into the silence and the answer still has to be spoken: five seconds after an interruption the agent has no way left to deliver it.

One capability, not many thin ones

Prefer one meaningful business capability per tool over several thin ones. The model picks book_appointment more reliably than it sequences check_availability, create_booking and send_confirmation — and the sequence is exactly the part it gets wrong. Chain those calls inside the operation tree, where the order is yours. The exception is destinations: one tool per transfer destination, never one tool that branches. See transfer.

Building one end to end

Create the tool, publish it, then attach it to an agent by id. The example reads an order status over HTTP and speaks the answer itself.
Two things about that tree are worth naming. SHOP_API_KEY must already exist as a workspace secret — publish fails on a secret that does not. And because the only operation that could return a result is marked silent, the tool is silent: the agent speaks the say line and adds nothing after it. Then attach it to an agent. An agent write takes the whole config, so read the current one and send it back with the tool added:
Leave tool_version out. A draft agent tracks whatever version of the tool is published now; publishing the agent pins the version that is live at that moment. Republishing a tool therefore changes nothing on live calls until the agent is published again — see versions.

Defining a tool inline

An entry in an agent’s tools may carry {"tool": { … }} — a whole tool written in place of an id — so an agent and its tools can be built in one request. On an agent this is a shorthand, not a second kind of tool: the write creates it, publishes it at v1, and stores {"tool_id": "…"} in its place, after which it is an ordinary tool. Attaching an existing tool is still tool_id, and one entry cannot carry both.

In the dashboard

Tools live under Build → Tools. The list shows each tool’s signature — the name and its arguments, which is what the model is shown — its description, whether it is a draft or Live v<n>, and which agents attach it. The editor has three cards, Configuration, Arguments and Operations, with Save, Validate, Test and Publish across the top.

Next

Schema and description

The three fields that decide whether the model calls the tool correctly.

The operation tree

The eleven operation kinds, on_error, and the branching rules.

Templating and data

The six template roots, tooldata vs userdata, and publish_fields.

Testing and publishing

Test runs, validation, versions and the pin-at-agent-publish rule.