> ## Documentation Index > Fetch the complete documentation index at: https://dialnexa.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Add Workflow Node > Use the add_workflow_node MCP tool on the DialNexa remote MCP server. 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 | Name | Type | Required | Description | | ------------- | ------------------------------------------------------------------------------------------ | -------- | ---------------------------------------------------------------------------------------------------------- | | `workflow_id` | `string` | Yes | The workflow ID, e.g. workflow\_abc123 | | `node_type` | enum: `VOICE_CALL` \| `CONDITIONAL` \| `TIME` \| `APPLICATION` \| `CONVERTED` \| `DROPPED` | Yes | The node type | | `label` | `string` | Yes | Short human-readable label for this node, e.g. "Initial Call" | | `config` | `object (free-form)` | No | Node-specific config matching the shape for node\_type described above. Omit or \{} for CONVERTED/DROPPED. | ## 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. ```json theme={null} { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "add_workflow_node", "arguments": { "workflow_id": "workflow_abc123", "node_type": "VOICE_CALL", "label": "VALUE" } } } ``` The server returns one text content block. Parse `content[0].text` as JSON when the tool succeeds. See [MCP responses and errors](/docs/mcp-tools/errors) for the full envelope and failure behavior. ## Verify the result Confirm the response is not marked `isError`. Call [Get Workflow Structure](/docs/mcp-tools/workflows/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. ## Related MCP tools * [Update Workflow Status](/docs/mcp-tools/workflows/update-workflow-status): `update_workflow_status` * [Get Workflow Structure](/docs/mcp-tools/workflows/get-workflow-structure): `get_workflow_structure` * [Add Workflow Edge](/docs/mcp-tools/workflows/add-workflow-edge): `add_workflow_edge` * [List Workflows](/docs/mcp-tools/workflows/list-workflows): `list_workflows` * [Get Workflow](/docs/mcp-tools/workflows/get-workflow): `get_workflow` ## Related guides * [Connect to the DialNexa MCP server](/docs/mcp-tools/overview) * [Workflows MCP tools](/docs/mcp-tools/workflows/overview) * [MCP responses and errors](/docs/mcp-tools/errors)