Gydmation

Edit part of a workflow

update_workflow_partial

Edit an existing n8n workflow with small operations instead of
resending the whole JSON. Operations (applied in order):
  {"op":"add_node","node":{name,type,typeVersion,parameters,credentials?,position?}}
  {"op":"remove_node","name":"..."}            (also removes its connections)
  {"op":"update_node","name":"...","parameters":{...merged...},"set":{"typeVersion":2,"disabled":false,...}}
  {"op":"rename_node","name":"old","new_name":"new"}   (connections follow)
  {"op":"add_connection","from":"A","to":"B","output_index":0,"input_index":0,"type":"main"}
  {"op":"remove_connection","from":"A","to":"B","type":"main"}
  {"op":"set_name","name":"..."}
  {"op":"set_settings","settings":{"timezone":"Asia/Kolkata","errorWorkflow":"..."}}
The result is validated first. If n8n accepts in-place updates the
workflow is updated directly; otherwise it is saved as "... (updated)".

Args:
    workflow_id: The workflow to edit.
    operations: List of operations as above.
    dry_run: Apply and validate only; return the result without saving.

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": {
      "workflow_id": "<workflow_id>",
      "operations": "<operations>"
    },
    "name": "update_workflow_partial"
  }
}

Input Schema

Name	Required	Description	Default
`dry_run`	No
`operations`	Yes
`workflow_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 24, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Goes well beyond the annotations: it discloses pre-save validation, the fallback of writing a '... (updated)' copy when in-place update is rejected, and which ops cascade (remove_node also drops connections, rename_node moves connections). It doesn't note that destructiveHint=false still covers node/connection removal, but the removals are disclosed in the op list, so no real contradiction.

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 summary sentence, then a scannable op catalogue, then fallback semantics, then args — good ordering with no filler. It is on the long side, but every line (especially the op examples) carries information an agent needs.

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 free-form, zero-coverage parameter tool with no output schema, this is close to complete: mutation semantics, validation, fallback, and dry_run are all covered. The one gap is the return shape — what a dry_run result looks like versus a successful save (ids, warnings, validation errors) is only gestured at.

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?

Schema coverage is 0%, so the description carries the entire burden and does: all three parameters are explained, and the free-form 'operations' array is pinned down with eight literal op shapes including field names, defaults like output_index/input_index/type, and merge semantics for update_node. This is more than the schema could ever convey for an additionalProperties object.

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

Purpose4/5

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

States a specific verb and resource ('Edit an existing n8n workflow') and sharpens the scope with 'with small operations instead of resending the whole JSON', which is exactly what separates it from a full-save sibling. It never names save_workflow or generate_workflow outright, so the differentiation is implied rather than explicit.

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?

The phrase 'instead of resending the whole JSON' gives a clear selection rule against the full-overwrite path, and dry_run is explained as 'Apply and validate only; return the result without saving.' There are no explicit when-not conditions, e.g. that whole-graph rewrites or brand-new workflows belong in other tools.

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

All Gydmation tools Inspect

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.