Tools is where you connect an agent to your own systems — the actions it can call while it reasons, like creating a ticket or looking up a record.
Overview
The Tools table lists the agent's custom tools: the connector actions, MCP servers, custom HTTP endpoints, and workflows-as-tools you've added. Add one with Add tool, which opens straight to "Select the app you want to connect."
A tool is something the agent does — different from a built-in capability (a ready-made function you just switch on), a skill (reusable expertise), and a task (a whole journey). The built-in standard tools no longer live here: they moved to the Capabilities section.
Adding a Connector or Workflow as a Tool
In the add-tool drawer, Select the app you want to connect, then Select an action for it, choose a Connection if the app needs one, and Configure the tool. Beyond standard connectors you can also add:
An MCP server tool (to call tools exposed over the Model Context Protocol).
A Custom HTTP Endpoint.
A workflow/automation as a tool (a callable automation the agent can invoke).
A custom application you build yourself (import its endpoints and auth).
This lets the agent act in your real systems — create a ticket, look up a record, run an automation — as part of answering.
Configuring a Tool's Inputs, Controls, and Output
Configuring a tool has three tabs:
Tab | What it covers |
|---|---|
Input | The action's inputs; you can bind them to values or let the agent fill them. A Test button runs the tool with the inputs you give; where an input is a lookup, pick from the fetched options or choose Enter custom value to supply one that isn't listed. |
Controls | Execution guardrails: Require approval before tool execution (the agent asks the user for approval every time, optionally remembering each user's choice), Governance ("conditional rules that determine when the agent can execute this tool"), a Rate Limit Policy (scoped per agent or per user), a Total Invocation Cost, Cache Management, and Retry on Error (automatically re-run the tool when it fails, with a retry count, an initial and maximum delay in milliseconds, and a backoff factor). |
Context | The name and description the agent reasons over (write these clearly so the model knows when to use the tool), the Tool output (Send full response or Send partial response, then pick which fields the agent receives), and — for connector tools — the tool's connection: you can change it here after the tool was added (only active, authenticated connections are offered; re-authenticate an inactive one first), or tick the option to use the end user's own runtime connection. |
A clear name and description plus the right output fields make the difference between an agent that calls a tool correctly and one that doesn't.
Connection and Approval Pills
Two pills flag how a tool behaves:
End user (Connection column) — the tool uses the end user's connection at runtime rather than a fixed one, set by the Use end user's connection at runtime for this tool toggle. Use it when each user should act with their own credentials.
Required (Approval column) — the tool requires approval before it runs, so the agent pauses for a person to allow the action.
Each row shows an On toggle you can switch off to disable the tool without removing it, plus Configure and Delete actions. Deleting always asks Delete Tool? — "Are you sure you want to delete the tool '{name}'? This cannot be undone."
Note: Built-in capabilities are managed separately, in the Capabilities section, not in this table. The table's columns are Tool, Description, Connection, and Approval.
Why Tools Might Look Empty
Because the table counts custom tools only. An agent that relies purely on built-in capabilities — web search, code execution, document creation — shows the Tools empty state, since capabilities aren't listed or counted here. That's expected, not a fault: check the Capabilities section to see what the agent can already do, and use Add tool only when you need to reach one of your systems.
What Happens When a Tool Runs
Each tool call goes through a fixed sequence:
The user sees a status message for the step — the agent's reasoning, or a configured static status line for that tool, with "Handling your request..." as the fallback (you can hide these, or hide just the tool name, in response-generation settings).
If the tool requires approval, execution pauses until the user decides.
The tool's Governance, Rate Limit, and Cache Management controls are evaluated — a cached result can be returned without running the tool at all, and a rate-limited call is refused.
The tool executes and its output is post-processed: it can pass through the tools guardrail wrapper, and PII/redaction patterns are applied before the model sees anything.
The (possibly trimmed/partial, per your Tool output setting) result is written into the conversation as the tool result, and the agent reasons over it in the next step. Tool name, input, and output are stored with the message — that's what the session view shows and what repetition detection compares.
If the tool fails and Retry on Error is on, the tool is retried first. The error goes back to the agent only after the retries run out. The conversation doesn't stop: the error text is fed back to the agent as the tool's result so it can retry differently or answer without it. After 3 failed steps in one turn, the agent is instructed to stop using tools and give its best final answer.
What Require Approval Looks Like When It Triggers
At runtime the agent pauses and shows the user exactly what it wants to run: the tool's name and its full input, rendered as readable YAML (internal connection identifiers are stripped first). The user approves or denies:
Approve — the tool runs and the agent continues. If you enabled the store-user-approval-preference option, an "always allow" choice is remembered per user and per tool, so that user isn't asked again.
Deny — the tool is not executed. The agent instead receives "User has denied to execute this tool." as the result and continues reasoning from there — typically explaining it can't proceed or trying another path.
There's also a session-level skip: automated runs (like evaluations) can bypass approval prompts entirely with the skip-approval option.
Do Tools Run One at a Time or in Parallel?
When the model asks for several tools in a single step and parallel tool-calling is active for that call, the runtime launches all of them at once as independent executions and waits for every result before the agent reasons again. One tool failing doesn't cancel the others — each failure just returns an error result for that tool. Single tool calls run inline, one at a time.
Can an Agent Call Other Agents as Tools?
Not from the Tools section. Sub-agents are added under Tasks (where you add other AI agents to a journey), and third-party agents are connected as external agents on their own tab. The Tools section is for tools, connector actions, MCP servers, custom endpoints, and workflows-as-tools — not for adding agents.