All nodes/AI/Agents

WF tool

Wraps a subgraph as an agent tool. The agent calls WF Tool by name, the chain of inner nodes runs (port «Data»/input → … → port «Result»/result), and the result is returned to the agent. Lets you build reusable tools out of nodes.

WF toolT▶

ResultAgent

Data

Type in the graph: wf_tool

ToolExec

Ports can be split into separate execution and data handles.

Try it

Minimal working workflow

Entry

WF toolT▶

Exit▶

Execute + Data

Press “Copy nodes”, open the editor and hit Ctrl+V on the canvas.

Runs as pasted

When to use it

Reach for a WF tool when the agent’s tool is a chain of your own nodes: call an API, parse the response, assemble the text. Try the ready-made tools first (RAG Tool, File Tool, Calendar Tool, Telegram Tools, MCP Tool) — they already cover the common cases — and use Toolset to gather several tools into one agent port. Composite answers a similar but different question: it groups nodes into a subgraph inside the main flow, whereas a WF tool exists only as a model call.

How it works

The node has three ports. Agent connects to the agent’s extensions port (a link_extension wire) — that is a registration, not a value. Data is where the subgraph starts and Result is where it ends.

When the model calls the tool, the arguments it supplied arrive as a single object on the Data port. The first node of the subgraph reads them through its own input: {{ inputs.input.order_id }} when the edge lands on its input port.

Every node lying on a path from Data to Result runs. The value that ends up at Result is returned to the model; anything that is not a string is serialized as JSON.

Arguments are described in Tool parameters — with the field builder or as raw JSON Schema, switched by Schema Mode. With Strict JSON Schema on, every declared property counts as required, so an optional argument means turning strictness off.

Tool name is lowercased, everything outside letters, digits, _ and - becomes _, and the result is cut to 64 characters.

Common mistakes

A generic name and an empty description. Several WF tools on one agent are told apart by name and description alone — “Run a workflow subgraph” tells the model nothing.
An unclosed subgraph. If nothing leaves Data or nothing enters Result, the call fails. So does a cycle inside the subgraph, or a node whose execution input nobody activates.
Routing the result to an exit. The subgraph has to end at the Result port: the result goes to the model, not to the workflow output. The reply to the user is written by the agent.
Expecting the subgraph to run on its own. The nodes inside run only when the model calls the tool. If it never does, they are absent from the run log.

Inputs

Port	Wire	Payload	Notes
Result`result`	Execute + Data`execute_data`	—	Execution and data from subgraph; wires to inner graph end port.

Outputs

Port	Wire	Payload	Notes
Agent`output`	Extension`link_extension`	—
Data`input`	Execute + Data`execute_data`	—

Configuration

Field	Type	Default	Description
Tool name`tool_name`	`string`	`wf_tool`	Function name the agent calls. Make it specific: several WF Tools on one agent are told apart by name and description alone.
Description`tool_description`	`string`	`Run a workflow subgraph with the given arguments.`	What the tool does and when to call it — this is all the model has to decide with.
Schema Mode`schema_mode`	`string`	`builder`	How the parameters schema is authored: field builder or raw JSON Schema. Options: `builder` — Fields Builder, `json` — Raw JSON Schema
Tool parameters (JSON Schema)`structured_output`	`object`	`{"type":"object","properties":{"input":{"description":"Input for the workflow…`	Arguments the agent must supply when calling this tool. Defaults to a single required string so the tool spec is valid out of the box — replace it with the arguments the subgraph needs.
Advanced
Strict JSON Schema (OpenAI)`strict_schema`	`boolean`	`true`	Ask the provider to enforce the schema exactly. Every parameter then counts as required — turn this off if an argument is optional.

Shared fields

Every node has these three — the platform adds them, not the node author.

split_ports_in — Show separate execution and data input handles instead of one combined port.
split_ports_out — Show separate execution and data output handles instead of one combined port.