Volanea

volanea_update_workflow

Idempotent

Update a workflow by id — edit the graph/trigger, or set status to 'active' (start processing live events) or 'paused'. Activation is deliberately separate from creation so a human-reviewable draft always exists first. graph replaces the stored graph wholesale, so read it with volanea_get_workflow first if you are amending one.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	New display name. Omit to leave it unchanged — this is a partial update, not a replace.
`graph`	No	Automation graph. Exactly one `trigger` node is the entry point; edges connect node ids. Node types and their `config`: - trigger: entry node, no config. - send_email: { templateId? } and/or { subject?, body? (HTML), fromEmail?, fromName? } — template fields fill anything omitted. - delay: { minutes?, hours?, days? } (defaults to 1 minute if all omitted). - wait_event: { event: "<eventName>", timeoutHours? (default 72) }. The unlabeled outgoing edge fires when the event arrives; an edge labeled "timeout" is taken on timeout. - condition: { conditions: <same condition tree as segments> }. Outgoing edges must be labeled "yes" and "no". - update_contact: { set: { <customField>: value, ... }, subscribed? }. - webhook: { url, payload? } — POSTs workflow/contact context to your URL (5s timeout). - exit: ends the walk. `x`/`y` are canvas coordinates for the dashboard editor — space nodes out (e.g. x = index * 260, y = 80).
`status`	No	`draft` and `paused` workflows enrol NO ONE: matching events are silently ignored, which is the usual reason a workflow "does not fire". Set `active` to go live — that starts affecting real contacts immediately.
`reentry`	No	Whether a contact can enter again. `never` = once per contact, ever (welcome series). `after_exit` = again once they have finished (abandoned cart). `always` = every trigger enrols them, even mid-run — the only option that can send one contact overlapping copies, so choose it deliberately.
`trigger`	No	Event name that enrols a contact, e.g. `order.placed`. Must match what your app actually sends, character for character: a mismatch is not an error, it simply never fires. Check volanea_list_resources { event_names } for what this project has really recorded.
`workflowId`	Yes	The wf-… id.

Output Schema

TableJSON Schema

Name	Required	Description
`code`	No	Machine-readable failure code to branch on. Present only when success is false.
`data`	No	Present when success is true.
`error`	No	Human-readable failure reason. Present only when success is false.
`success`	Yes	False when the call failed; read `error` and `code` in that case.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 17, 2026

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations supply only idempotentHint, so the description carries meaningful extra weight: it warns that `graph` replaces the stored graph wholesale (destructive to omitted nodes) and that going 'active' starts processing live events immediately. It does not cover permissions, rate limits, or failure modes, so it is strong but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the what and the two modes, followed by the design rationale and the one hazard an agent most needs to know. No sentence is filler and nothing is buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nested-object, six-parameter mutation tool with an output schema, an idempotency hint, and 100% schema coverage, the description closes the remaining gaps: activation semantics, wholesale graph replacement, and the read-before-amend step. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning the schema does not: that `graph` is a wholesale replacement rather than a patch (contrasting the partial-update behavior documented for `name`), plus the read-first workflow. That is genuine added value above the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Update a workflow by id') plus the exact edit surface: graph/trigger or status. It also distinguishes itself from creation ('Activation is deliberately separate from creation'), so an agent can separate it from volanea_create_workflow without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for the two main modes (amend the graph vs. flip status live) and names volanea_get_workflow as the read-before-write prerequisite. It stops short of explicitly stating when NOT to use it (e.g. to create a new workflow, use volanea_create_workflow), leaving that inference to the sibling name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Volanea tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.