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 picksbook_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.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:
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’stools 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 orLive 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.