comfy-draftsman

Overview Schema Source Related Servers Discussions Admin

edit_workflow

Apply batched graph edits to a ComfyUI workflow: add/remove nodes, connect ports, set widgets, titles or modes, and update layouts or subgraphs.

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}
{"op": "set_widget", "node_id": int, "input": str, "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

All but replace_in_widget have a definition-scoped twin taking an extra "definition_id" for subgraph edits: add_node_to_definition, remove_node_from_definition, and connect/set_widget/set_title/set_mode_in_definition. A malformed op reports its own required keys.

Layout/group ops (no definition twin): set_pos {node_id, pos:[x,y], size?:[w,h]}; add_group {title, node_ids, color?}; set_group {group_id, title?, node_ids?, color?}; remove_group {group_id} ('#N' in inspect_workflow). organize_workflow re-lays out and re-groups, so run these after it.

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; a failing op stops the batch (graph unchanged past that point). Widget values and link types are checked live - "force": true on set_widget/add_node/connect overrides; on connect it also lets a frontend-only input (no /object_info entry - rgthree switches, dynamic collectors) be wired by creating the socket.

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

Input Schema

TableJSON Schema

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

Output Schema

TableJSON 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/5.0

Behavior4/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false) by disclosing batch semantics: ops apply in order, a failing op halts the batch with the graph unchanged past that point, and validation (widget values, link types) is checked live with 'force': true as an override. It notably does not call out that remove_node/remove_group are destructive, which the destructiveHint=false annotation does not surface either.

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?

Long but dense and front-loaded with the core action before the op reference; each bullet earns its place as an executable op signature. It is on the verbose side for a description, but little could be cut without losing invocation-critical detail.

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 complex, high-arity mutation tool with an output schema, the description covers the op grammar, ordering/failure behavior, validation and force semantics, virtual-class edge cases, and where slot names come from (get_node_info). An agent has everything needed to build a correct batch without opening the schema.

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 description coverage is 0%, so the description carries the full burden and does so thoroughly: every op shape, its required keys, and which keys are optional is spelled out (e.g. add_node's class_type/ref/widgets, replace_in_widget's single-match 'old', set_mode's 0/2/4 codes). This is far more than the bare schema provides.

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+resource ('Apply batched edits') and then enumerates the exact operation vocabulary (add_node, connect, set_widget, etc.), so an agent knows precisely what capability this exposes. It also distinguishes itself from siblings by naming the definition-scoped twins and organize_workflow/inspect_workflow as related tools.

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 real sequencing guidance: layout/group ops should run after organize_workflow, and inspect_workflow/summary=true is offered when the compact delta is insufficient. It stops short of stating when NOT to use edit_workflow versus save_workflow or create_workflow, so it's clear context without explicit exclusions.

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