Skip to main content

Overview

Tools let your agent take actions during a conversation - look up a record, hold a slot, charge a deposit, query a database. On the Playbook engine (the default), tools live in the playbook’s process layer and are run by the Director, off the speech path, so a slow API call never stalls what the caller hears. Three tool shapes, one model:

Declaring tools in a playbook

A tool is a ToolSpec in the playbook’s tools: list. HTTP tools template their url/headers/body with sandboxed Jinja over {slots, env, results}; the response is stored under store_response_as and is then readable as results.<key> in guidance, advance rules, and other tools.
A checkpoint runs tools via its pipeline (on entry) or on_enter list. Tool failures are data, not exceptions - a failed HTTP status or template error is recorded as a failed result and routed declaratively, never a crash mid-call.

Pipelines

Chain tools with typed result branches. Each step routes on ok, failed, or an exact http_<code>; failures can retry (capped) and route on exhaustion.
A pipeline-owned checkpoint routes on pipeline.ok / pipeline.failed:
For auth that expires mid-call, one middleware entry refreshes a token and replays the step:

Python tools

Declare a python tool in the playbook by id, then bind the implementation. A Python tool is an async callable that receives the call args and the current state:
Through the unified DialogMachine entry point, pass any Tool and it is bridged automatically:

MCP tools

For servers that implement the Model Context Protocol. Requires pip install superdialog[mcp].
MCPTool connects lazily on first use and forwards execute(args) to the configured server. Auto-discovery of all tools an MCP server publishes is planned for a follow-up release.

Security model

The playbook artifact is data and the transcript is untrusted user speech. Tools are defended accordingly:
  • Sandboxed Jinja for all url/headers/body rendering - attribute-walking injection payloads are blocked, not executed.
  • Secret redaction in the event log - token/api-key/password/bearer-shaped keys and URL userinfo are masked before the ToolCallEvent lands; the real request still goes to the wire untouched.
  • The env lane is never rendered to the Talker - ACCESS_TOKEN-class values cannot leak into speech or the packed prompt.

Legacy: tools on the graph engine

On the legacy DialogMachine graph engine (engine="flow"), tools are registered as a list and the LLM calls them via tool-calling. This still works for graph flows.

@tool decorator and plain functions

Plain functions work too - SuperDialog wraps them using the function name as the id and the docstring as the description.

PythonTool / HttpTool

Function references on the flow model

Attach functions to ConversationFlow.tools (flow-level) or FlowNode.tools (node-scoped) when building graphs in Python:

Tool results and flow transitions

On the graph engine, a tool can trigger a transition by returning a ToolResult with transition_edge_id:
On the Playbook engine, outcome routing is done by advance rules and pipeline branches instead - a tool result is stored under store_response_as and read by judge: expr rules. There is no transition_edge_id.