Tools

Tools are how the agent does real work during a call: look up an order, book a meeting, search a knowledge base, transfer to a human, end the call. The model reads each tool's description and decides when to call it. A tool's description is the highest-leverage prompt surface you have, so write it as carefully as the prompt itself.

Two kinds of tool

Builtin tools are actions the platform ships and runs for you:

• Transfer to a human — hand the call to a person.
• Book a meeting — schedule on a connected calendar.
• Search knowledge base — retrieve from the agent's knowledge base to ground an answer.
• Get the current time — the current time in the agent's configured timezone.
• End the call — hang up cleanly.

Webhook tools call your own HTTP endpoint. In the editor they show as "Webhook" with their method — GET or POST.

Anatomy of a tool

Each tool, in edit mode, is a stack of cards:

• Identity — the tool's name (lowercase, letters/digits/underscores, used to address it) and its plain-language description. The description is what the model reads to decide when to use the tool. Describe what it does and when to use it, in the words a caller's intent maps to.
• Built-in action (builtin tools) — the action to run.
• Request and Mock (webhook tools) — see below.
• Prerequisites — other tools that must succeed first.
• Fillers — phrases the agent can say while this tool runs.

Webhook tools: Request and Mock

A webhook tool has a Request card and a Mock card.

Request defines the live call:

• URL, headers, and params — any of which can contain variable tokens like {{booking_url}} or {{api_key}} that get substituted at call time.
• Params are described as a JSON Schema object — a set of properties and which of them are required. This is how the model knows what arguments to collect from the caller and pass in.
• A request body for POST tools.

Mock holds a canned response so you can test the agent's behaviour without hitting the real endpoint.

Prerequisites, not flows

A tool can declare prerequisites — a flat list of other tool names that must have run successfully first (for example, verify_caller before cancel_order). It is just a list of names, not a diagram. If the model tries to call a tool before its prerequisites are met, the runtime returns a "precondition unmet" result and the model corrects itself on the next turn — there is no ordering graph to draw and nothing to maintain by hand.

Parallel and filler markers

In the tool list you may see two markers:

• Parallel — the tool is safe to run alongside others, so the agent does not have to wait for one before starting the next.
• Fillers off — this tool runs without filler phrases.

Saving

Tool edits are saved explicitly — make your changes and save the tool. As with everything else, changes land in a draft and reach live callers only when you publish.

Writing good tool descriptions

This is where reliability is won or lost:

• Say plainly what the tool does and the situation it is for.
• Name the inputs it needs and when the agent should ask for them.
• Mention what it does not handle, so the model does not over-reach.
• Test with the test panel — if the agent calls a tool at the wrong moment, fix the description before touching the prompt.