apply_actions
Validate and apply a batch of flow-builder actions — the single write path for editing flows, blocks, variables, broadcasts, sequences, and folders. Call this directly; a separate validate_actions call beforehand is unnecessary. Broadcasts have no dedicated tool and are managed here: create_broadcast makes a DRAFT (it owns its flow via data.flowId — add the message blocks in the same batch, no separate create_flow), optionally with create_recurrence_schedule + attach_recurrence_to_broadcast for recurring — the attach makes it live at once (it sends at the next scheduled time) when the application has an active bot, so confirm the time and audience with the user first. For a one-time broadcast, a later update_broadcast with status SCHEDULED and scheduledAt is what schedules/sends it. The full recipe is in get_action_schema under broadcasts. DESTRUCTIVE: the batch may include delete_block, delete_link, delete_flow, delete_variable, delete_operation, and delete_broadcast. Confirm with the user before applying deletions. delete_operation also removes the operation's hidden graph flow and run history; delete_broadcast also removes the broadcast's delivery history and its content flow, and neither can be undone. IRREVERSIBLE SIDE EFFECTS: run_operation starts a real operation run, which may send broadcasts to real contacts and write application variables. It cannot be undone or recalled, is not idempotent, and is available only through this tool — confirm with the user before applying a batch containing one, and never blindly retry a timed-out call that did. Validation always runs first and an invalid batch applies nothing. If an action fails mid-batch, execution stops and the server tries to undo the steps already applied: reverted: true means nothing from the batch remains (fix the reported error and resend); reverted: false on a failure means part of it may still be applied (errorClass: "partial_write") — re-read state with get_flow_context before retrying rather than blindly resending the batch. errorClass is one of validation | rule | conflict | permission | partial_write | unknown. Not idempotent — resending a batch of create_* actions creates duplicates. Read get_action_schema for the action contract and get_design_guidelines before any structural edit. Returns { success, validated, reverted, errorClass (on failure), changes, errors, warnings, actionId } plus an idRemap mapping placeholder ids to the real ids that were created. Applying does NOT publish. Edits land on the draft graph and connected bots keep serving the previously published version until deploy_application runs — finish a round of edits, then deploy.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| flowId | No | Default flow id for actions in the batch that do not carry their own. Optional when every action targets an explicit flow. | |
| actions | Yes | Ordered batch of at least one action, applied in array order. An invalid batch is rejected up front and applies nothing, but execution itself is NOT atomic: if an action fails mid-batch, execution stops there and the actions before it stay applied — re-read state before retrying. | |
| applicationId | No | Application (workspace) id. Optional: an application-scoped key (app_...) defaults to its own application, but a personal key (usr_...) has no default and omitting it fails with MCP_APPLICATION_REQUIRED. Call list_applications to get the id. | |
| conversationId | No | Optional id used to group the resulting audit records under one editing session. |