Skip to main content
Changes state - verify before retry Adds a single node to an existing workflow. This is NOT a read-only action. Exactly 6 node types exist, each with its own required config shape:
  • VOICE_CALL: config = { phone_number_id: “phn_abc123”, outputs: { COMPLETED?: node_id, DNP?: node_id, FAILED?: node_id } }. Places a call using the agent bound to that phone number. outputs can be created empty ({}) — this is the ONE node type you can create before its targets exist, then wire up later with add_workflow_edge.
  • CONDITIONAL: config = { conditions: [{ field: “dynamic_variables.status”, operator: “equals”|“not_equals”|“exists”|“contains”|“greater_than”|“less_than”, value: ”…” }], logical_operator: “AND”|“OR”, outputs: { true: node_id, false: node_id } }. Both outputs.true and outputs.false are REQUIRED AT CREATION TIME — unlike VOICE_CALL, you cannot create this node first and wire it later. Create its true/false target nodes FIRST, then create this node with both real target ids already in outputs.
  • TIME: config = { duration: { value: 24, unit: “minutes”|“hours”|“days” }, output: node_id } to wait a fixed duration, OR { time_source: “postcall_analysis”, pca_field: “Time of Callback”, output: node_id } to wait until a post-call-analysis field’s value. output is REQUIRED AT CREATION TIME, same constraint as CONDITIONAL — create the target node first.
  • APPLICATION: config = { application_integration: “whatsapp”, wati_template_name: “template_name”, wati_template_params: [“param1”,“param2”], output: node_id }. WhatsApp (via Wati templates) is the ONLY application integration this tool supports — if the user asks for a different integration (email, Slack, etc.), tell them it isn’t available here rather than guessing a config shape for it. output is REQUIRED AT CREATION TIME, same constraint as CONDITIONAL/TIME.
  • CONVERTED / DROPPED: terminal nodes, config = {} (or omit), no outputs concept at all. Every workflow needs at least one of each before it can be activated. They can never be the SOURCE of an edge — execution stops there.
Build order matters and differs by node type: VOICE_CALL nodes can be created empty and connected later. CONDITIONAL/TIME/APPLICATION nodes CANNOT — their target node(s) must already exist before you create them, with the real target id(s) already in outputs/output (the underlying validation rejects creating them otherwise). A practical order: create terminal nodes (CONVERTED/DROPPED) and any VOICE_CALL nodes first, then build CONDITIONAL/TIME/APPLICATION nodes working backwards from those targets, filling in real ids as you go. Regardless of node type, ALWAYS follow up by calling add_workflow_edge for every connection, even ones already set inline in a node’s outputs/output at creation time — add_workflow_edge is what creates the structural connection (workflow_edges) that activation’s reachability check reads; setting outputs/output directly only sets the runtime routing, not the structural connection, so skipping add_workflow_edge means activation will report the target as unreachable even though it would work fine at call time. Calling add_workflow_edge for a pair whose config is already correct is safe — it just confirms the structural edge, no error. Graph shape rules — these are ONLY checked when you activate (update_workflow_status, action “activate”), never while you’re adding nodes/edges, so a graph can look finished and still fail to activate if you didn’t keep these in mind while building:
  1. Exactly ONE node may have zero incoming edges — that’s the entry point every lead starts at. Every other node needs at least one incoming edge from add_workflow_edge. Two disconnected starting points, or a node nobody points to, both fail activation.
  2. Every node must be reachable from that entry point by following edges forward — a node created but never wired to anything fails activation as unreachable.
  3. No cycles, ever — this one IS checked immediately on add_workflow_edge (rejected and rolled back on the spot), not deferred.
  4. At least one CONVERTED and one DROPPED node must exist and be reachable. Before calling update_workflow_status with action “activate”, call get_workflow_structure and check points 1, 2, and 4 yourself — catching a broken connection there is far clearer for the user than an activation error. Adding a node does not connect it to anything by itself — use add_workflow_edge afterward, or reference other node ids directly inside this node’s outputs/output config.

​
Parameters

​
Before you call

  • Connect and initialize the MCP client with OAuth or an API key for the intended workspace.
  • Provide the required parameters: workflow_id, node_type, label.

​
Example MCP request

Send tools/call after your client completes MCP initialization. Replace placeholder values with IDs and inputs from your workspace. For object and array parameters, follow the nested requirements in the parameter description instead of treating an empty value as complete.
The server returns one text content block. Parse content[0].text as JSON when the tool succeeds. See MCP responses and errors for the full envelope and failure behavior.

​
Verify the result

Confirm the response is not marked isError. Call Get Workflow Structure to read the affected resource. Verify that the intended state is visible before making another change.

​
Retry safety

This tool changes workspace state. After a timeout, read the affected resource before retrying so you do not create duplicate or conflicting changes.