comfy-draftsman

Overview Schema Source Related Servers Discussions Admin

edit_workflow

Apply ordered, all-or-nothing batches of node, link, widget, and layout edits to ComfyUI workflows, returning a delta or full summary.

Instructions

Apply batched edits. Each op is a dict with 'op' plus:

{"op": "add_node", "class_type": str, "title"?: str, "ref"?: str, "widgets"?: {name: value}} # later ops may use a ref as a node id
{"op": "remove_node", "node_id": int}
{"op": "connect", "from_node": int, "from_output": str|int, "to_node": int, "to_input": str} # replaces a link
{"op": "disconnect", "node_id": int, "input": str}
{"op": "set_widget", "node_id": int, "input": str | "index": int, "value": any}
{"op": "replace_in_widget", "node_id": int, "input": str, "old": str, "new": str} # 'old' must match once
{"op": "set_title", "node_id": int, "title": str}
{"op": "set_mode", "node_id": int, "mode": int} # 0 normal, 2 mute, 4 bypass
{"op": "set_resolution", "width": int, "height": int} # all latents + size patches
{"op": "copy_nodes", "from_workflow": id, "node_ids": [int], "ref"?: str} # + links among them

Subgraph twins add "definition_id": add_node_to_definition, remove_node_from_definition, connect/set_widget/set_title/set_mode_in_definition.

Layout ops (no twin): set_pos {node_id, pos:[x,y], size?:[w,h]}; set_color {node_id, color, bgcolor?}; add_group {title, node_ids, color?}; set_group {group_id, title?, node_ids?, color?, bounding?:[x,y,w,h]}; remove_group {group_id} ('#N' in inspect_workflow). organize_workflow redoes all layout.

Slot/widget names come from get_node_info. Virtual classes: Note/MarkdownNote take one widget 'text'; Reroute/PrimitiveNode take none at add - connect a PrimitiveNode to a widget input to mirror its type, then set_widget 'value' (+ 'control_after_generate' for number/combo, to advance each run).

Ops apply in order, all or nothing (a failing op changes nothing). Widget values and link types are checked live - "force": true on set_widget/add_node/connect overrides; on connect it also creates a frontend-only input (rgthree switches, dynamic collectors).

Result is a delta; summary=true gives the full graph.

Input Schema

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

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.15.1Aug 23, 2026
- removedInput schema / properties / operations / title
```
Removed value: -"Operations"
```
- addedInput schema / properties / summary
```
Added value: +{
+  "default": false,
+  "type": "boolean"
+}
```
- removedInput schema / properties / workflow_id / title
```
Removed value: -"Workflow Id"
```
- removedInput schema / title
```
Removed value: -"edit_workflowArguments"
```
First observedv0.2.0Jul 7, 2026

TDQS

A4/5.0

Behavior5/5

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

Substantially exceeds what the annotations declare: atomicity ('all or nothing — a failing op changes nothing'), live type checking of widgets and links, the 'force': true override and its side effect of creating frontend-only inputs, and the delta-vs-full-graph return behavior with summary=true. These are exactly the operational facts an agent needs before issuing a batch and are not available in structured fields. Minor tension: destructiveHint=false while remove_node/remove_group genuinely delete nodes and links, though this is arguably reversible graph editing rather than a hard 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 with the core action, then organized as a scannable per-op reference where each line earns its place by defining one operation. Some passages are over-compressed to the point of ambiguity, notably the run-on 'Subgraph twins add ...' sentence which requires re-parsing to determine the mapping between base ops and their _in_definition variants.

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?

An output schema exists, so not explaining return values is appropriate, and the description still usefully clarifies delta vs. full graph. Coverage is strong for a 12-plus-operation batch tool, with the main omission being how to obtain a valid workflow_id and what happens on failure beyond the all-or-nothing guarantee.

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 coverage is 0%, so the description must carry the load — and it does, effectively serving as the real spec for the operations array, including per-op required fields and semantics like 'replaces a link' on connect and 'must match once' on replace_in_widget. The offsetting gap is workflow_id, which is never explained (format or source), and summary's effect is only mentioned in passing at the end.

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?

The opening sentence, 'Apply batched edits,' pairs a specific verb with a clear resource (a workflow graph), and the enumerated op list makes the scope unmistakable. It does not, however, explicitly distinguish itself from siblings like create_workflow or save_workflow, so an agent must infer the boundary between editing an existing graph and creating/persisting one.

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

Usage Guidelines3/5

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

Usage is implied by the op grammar rather than stated: there is no 'use this when...' guidance and no explicit alternatives for graph mutation. The single routing hint present ("organize_workflow redoes all layout") is a caveat, not a when-to-use rule, so the agent must derive selection criteria on its own.

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