Skip to main content
Glama
Sign In

Meridian

by ai.the-meridian
OverviewDiscussions(2)Admin

Update Automation

automation_update

Updates an automation's name, description, and/or draft graph. Status cannot be set through MCP (activate/deactivate in the dashboard). Graph updates are only allowed while the automation is inactive; metadata updates are always allowed. Graphs must not include emailHtml. Reference emailUuid instead. Takes app_id and automation_id (scoped_id or uuid).

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": {
      "app_id": "<app_id>",
      "automation_id": "<automation_id>"
    },
    "name": "automation_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoNew display name.
graphNoDraft automation graph: `{nodes: [...], edges: [...]}`. Only accepted when the automation is inactive. Must not include emailHtml. A node has `node_id` (string), `type` (trigger, action or condition), `position` and `data`. An edge has `edge_id`, `source` and `target` (node ids), and `sourceHandle` (yes or no) when it leaves a condition. `id` and `key` are accepted in place of `node_id` / `edge_id` (priority `id`, then `node_id` / `edge_id`, then `key`). An edge with no identifier gets one; a node needs one. `templates[].graph` from `automations_catalog_get` and `graph` from `automation_get` can be passed as is.
app_idYesThe app uuid returned by `apps_list`.
descriptionNoNew description, up to 2,000 characters. Pass null to clear.
automation_idYesThe automation scoped_id or uuid returned by `automations_list`.
organization_idNoAn organisation uuid or slug. When supplied, `app_id` is resolved within that organisation and may be a slug instead of a uuid, mirroring the Meridian web app.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations only declare it is a non-destructive, closed-world mutation; the description adds real behavioral context beyond that — the inactive-state gate on graph writes, the always-allowed metadata path, and a content prohibition (`emailHtml`). It does not say what happens on rejection (error vs. silent ignore) or whether graph updates replace or merge, which keeps it from a 5 and is consistent with destructiveHint=false.

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 action, then constraints in descending priority; nearly every sentence carries a rule an agent needs. The closing "Takes `app_id` and `automation_id` (scoped_id or uuid)" partially duplicates the schema's required fields and descriptions.

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

Completeness4/5

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

For a mutation with a nested graph object and no output schema, the description covers the high-risk parts well: activation gating, field scope, and the emailHtml exclusion. It leaves a gap on outcome semantics — what the caller gets back and how a rejected graph update surfaces — which matters somewhat more since no output schema exists.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents all six parameters in detail, including the nested graph shape. The description restates the required identifiers and adds a small amount of meaning (`emailUuid` instead of `emailHtml`, scoped_id-or-uuid), so it sits at the baseline rather than adding substantial new semantics.

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 specific verb and resource plus the exact updatable fields: "Updates an automation's `name`, `description`, and/or draft `graph`." The "and/or" makes the partial-update semantics explicit, and the mention of 'draft graph' plus the status restriction separates it from create/get siblings.

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 concrete preconditions: graph edits only when the automation is inactive, metadata edits always allowed, and status changes must go through the dashboard rather than MCP. It names no explicit alternative tool, but the dashboard redirect covers the main misuse case.

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

All Meridian toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources