Using the AI
The agent's toolbox is built from the same action registry that powers the API. Every action becomes one tool; the agent selects tools by name and the AI SDK validates arguments with the action's own schema before the handler runs. One source of truth — see Core Concepts.
How a tool is named and described
- Name: the action name with dots → underscores.
missions.createbecomes the toolmissions_create. - Description: the action's description, plus any
llmHintsappended as "When to call" guidance, plus a note when the action is mutating.
The hints are how you steer the agent toward the right tool. The Reference shows each tool's name, description, and hints.
Mutating actions & autonomy
A mutating tool changes platform state. How that's handled depends on the agent's autonomy level:
- Autonomous agents execute mutating tools directly.
- Supervised agents queue a Decision instead, for a human to approve or reject before the change lands.
After a mutating tool runs, the result carries a refresh hint so any open UI reflects the change without a manual reload.
Errors are real failures
When a tool's handler throws, the agent sees a genuine failure (not a success
containing an error field). This stops the agent from marching ahead with IDs
that were never created. Database errors are flattened to their underlying
cause so the agent gets an actionable message.
Beyond native tools
The agent's toolbox also includes, when configured:
- Composio integrations — one tool per connected third-party action (Twitter, LinkedIn, etc.), available once an account is connected.
- Extension MCP tools — namespaced
ext__<extension>__<tool>, connected per request from each enabled extension's MCP server. - Extension actions marked
exposeAsTool— surfaced asext_<ext>_<action>.
See Integrations and Extensions.