Skip to main content
Glama
Arsel MCP Server

Arsel MCP Server

Official
by Arsel-SA

Update Automation

update-automation
Destructive

Rename an automation or replace its workflow steps and connections while keeping omitted fields unchanged. Use it to fix validation issues or update a graph before the user enables it.

Instructions

Rename an automation or replace its steps. Omitted fields are unchanged.

steps with connections REPLACE the whole graph: read it with get-automation, edit it and send all of it back, keeping each step's key. The steps of an enabled automation cannot be replaced: tell the user to disable it in the Arsel dashboard first, or build the change on a copy from clone-automation. The steps of a disabled one take effect when the user enables it again, so confirm with the user first, naming the automation. This server cannot enable or disable an automation: once issues is empty, the user turns it on from the Arsel dashboard. Saving steps messages nobody.

Shape. An automation is a graph. steps holds every step, the trigger included (key trigger), and connections link them by key. A step leaves by default, except a condition (condition_met, condition_not_met) and a wait_for_event (event_received, timeout). A branch with no connection ends the run. Every step must be reachable from the trigger, no connection may lead back to an earlier step, and branches that split must rejoin at one step or not at all. At most 100 steps.

Look up what the steps name before writing them. Tags from list-tags, lists from list-lists, segments from list-segments, email templates from list-templates, sending domains from list-email-domains, SMS senders from list-sms-senders, WhatsApp templates from list-whatsapp-templates, custom properties from list-contact-properties, events from list-events, campaigns from the channel's campaign list tool.

Conditions and waits take a filter in the segment rule format. To react to a message this automation sent, use a message_engagement rule with target_type: automation_step and the send step's key as target_id; that step must always run before.

Drafts may be unfinished. The automation comes back with issues, each naming a step_key and the config path still missing or wrong. Fix them with update-automation. A graph that breaks a rule of the shape above is refused and nothing is saved.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "update-automation"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe automation id.
nameNo
stepsNoEvery step, the trigger included. Send it with `connections`; together they replace what was there.
connectionsNoSend it with `steps`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes far beyond the annotations (destructiveHint=true, idempotentHint=false) by disclosing that sending steps+connections replaces the entire graph, that a rule-breaking graph is refused with nothing saved, that saving steps sends no messages, and that disabled-automation edits only take effect on re-enable. It also explains the failure surface (issues with step_key and path). No contradiction with the destructive hint.

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

Conciseness4/5

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

Front-loaded with the core action and cleanly sectioned with bold headings (Shape, lookup guidance, Conditions and waits, Drafts). It is long, and a few rules (branch exit names, 100-step cap) restate schema detail, but almost every sentence carries distinct operational guidance.

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 graph-replacing mutation with no output schema, the description covers preconditions, validation rules, refusal behavior, the shape of the returned issues, and the follow-up call. Nothing material an agent needs to invoke it correctly is left to inference.

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

Parameters5/5

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

Adds substantial meaning beyond the 75%-covered schema: the trigger must be keyed 'trigger', keys must be preserved when round-tripping, branch exit names per step type, reachability/no-back-edge/rejoin/100-step rules, and a lookup table mapping each referenced entity to its list-* tool. This is exactly the cross-field semantics the schema cannot express.

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?

Opens with a precise verb+resource pair ('Rename an automation or replace its steps') and immediately qualifies semantics with 'Omitted fields are unchanged.' It also implicitly separates itself from create-automation and explicitly routes to clone-automation for the copy-first path, so an agent can place it among siblings without reading the schema.

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

Usage Guidelines5/5

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

Gives explicit when/when-not rules: an enabled automation's steps cannot be replaced, so use clone-automation or have the user disable it in the dashboard; confirm with the user before writing steps to a disabled automation; fix reported issues by calling update-automation again. It also states a hard limitation of the server (cannot enable/disable) and names the workflow for each case.

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

Deploy Server

Other Tools