> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thinnest.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Tool Node

> Run one integration action — send an SMS, create a calendar event, look up an order, push to a CRM — at a specific step in a Voice Workflow, and map the result into variables.

# Tool Node

The **Tool** node runs **one integration action** at the exact point you place it
in the flow — send a confirmation SMS, create a calendar event, look up an order,
push a record to your CRM — and maps the result back into the flow as
[variables](/docs/voice/workflows/transitions). It runs **instantly** (no caller
turn), then passes through to the next node.

<Info>
  **Why a node, when the agent can already use tools?** An agent decides *on its own*
  whether and when to call a tool — which means it might not, or might call it at the
  wrong moment. The Tool node makes the action **guaranteed and on-script**: at this
  step, exactly this action runs, with exactly these inputs. Use it whenever an action
  must happen at a precise point — taking a payment detail, firing a confirmation,
  booking a slot.
</Info>

## Tool node vs. API Request node

| Use the…                                                  | When you want to…                                                                                                                 |
| --------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| [**API Request** node](/docs/voice/workflows/api-request) | Call **your own** HTTP API or webhook.                                                                                            |
| **Tool node**                                             | Run one of the platform's **built-in integrations** (messaging, calendar, CRM, and more) — the same tools you attach to an agent. |

## Configure it

Select the node on the canvas to open the **Inspector**.

<Steps>
  <Step title="Pick an attached tool">
    Choose from the tools **already attached to this agent**. You don't re-enter
    URLs, accounts, or credentials — the node simply references the agent's tool, so
    its credentials stay on the agent and never live in the workflow.
  </Step>

  <Step title="Choose the function (optional)">
    Some tools expose more than one action. Name the **function** to run, or leave
    it blank for single-action tools.
  </Step>

  <Step title="Map the inputs">
    Under **Parameters**, map each input the action needs to a value template — for
    example `order_id` → `{{order_id}}`. Templates support `{{variable}}`
    interpolation, so inputs are filled from variables captured earlier in the call.
    A parameter that is exactly one `{{variable}}` keeps the variable's type
    (numbers stay numbers, booleans stay booleans).
  </Step>

  <Step title="Map the result (optional)">
    Use the **Response → Variable** mapping to land result fields (by **dot path**)
    into workflow variables, so a later [Condition](/docs/voice/workflows/nodes#condition)
    can branch on them. You can also store the whole result in one variable.
  </Step>
</Steps>

<Note>
  The Tool node runs the agent's existing tools — attach and configure them once in
  the agent's **Tools** panel, then reference them from any workflow step. For each
  tool's reference, see [Tools](/docs/tools).
</Note>

## How inputs flow in

Parameters are filled from workflow variables **before** the action runs, so by the
time the flow reaches the Tool node, earlier
[Conversation or Collector nodes](/docs/voice/workflows/nodes) should have captured
whatever the action needs. Declare those variables in the **Variables** panel and
make sure a preceding node collects them.

## Error handling

If the action fails, the node takes its **unconditional fallback edge** — the call
never hangs. Always give a Tool node a path to follow when the action doesn't
succeed, so the agent can apologize, offer an alternative, or transfer instead of
going silent. If you map a result field that signals success (or failure) into a
variable, a following Condition node can branch on it too.

## Worked example — confirmation SMS

<Steps>
  <Step title="Confirm the booking">
    Earlier nodes capture `{{caller_phone}}` and `{{appointment_time}}` and confirm
    the booking with the caller.
  </Step>

  <Step title="Send the SMS">
    A **Tool** node runs your messaging tool. Its parameters map `to` →
    `{{caller_phone}}` and `body` → a confirmation message that includes
    `{{appointment_time}}`.
  </Step>

  <Step title="Carry on or recover">
    On success the flow continues to a closing **Conversation** node; on failure the
    fallback edge routes to a node that offers to read the details out loud instead.
  </Step>
</Steps>

## Next steps

<CardGroup cols={2}>
  <Card title="API Request Node" icon="plug" href="/docs/voice/workflows/api-request">
    Call your own HTTP APIs and webhooks instead of a built-in integration.
  </Card>

  <Card title="Transitions & Variables" icon="code-branch" href="/docs/voice/workflows/transitions">
    Declare the variables the action reads and writes, and branch on its result.
  </Card>

  <Card title="Node Types" icon="table-list" href="/docs/voice/workflows/nodes">
    See how Tool sits alongside Knowledge, Condition, and the other internal nodes.
  </Card>

  <Card title="Tools" icon="wrench" href="/docs/tools">
    The full catalog of integrations you can run from a Tool node.
  </Card>
</CardGroup>