Skip to main content
Glama
EnragedAntelope

comfy-draftsman

by EnragedAntelope
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

run_workflow

Execute a ComfyUI workflow and return status, node errors, output files, and an inline preview. Queue without waiting to poll long renders.

Instructions

Queue the workflow and (by default) wait for completion. Returns status, node errors on failure, output file refs, any non-file return values (data_outputs: generated text, paths a save node wrote), and an inline preview thumbnail so you can SEE the result (view_output fetches full size). wait=False returns {status: queued, prompt_id} - poll get_run_status. Prove a workflow works before saving/delivering.

return_preview=False (text-only caller): no inline images, sweeps included; a file path comes back if save_dir/COMFYUI_MOUNT_DIR is set.

roll_seeds=True (default) mirrors the browser: randomize/increment/decrement seeds and PrimitiveNodes re-roll and persist before submit. False re-runs the stored values.

allow_invalid=True submits despite local validation errors (ComfyUI is the final judge). save_dir (or COMFYUI_MOUNT_DIR) relocates finished outputs into a folder the caller can reach (saved_paths); needs wait=True - a background run relocates later via save_output(prompt_id=...).

front: None (default) refuses to queue when >=2 prompts are pending and returns {status: queue_busy} so the USER can choose; True runs next; False waits at the back of the line.

confirm_spend: partner/API nodes charge per submit, so a graph containing one is gated - pass True only after they agree.

sweep={variants:[{label,ops}],seeds:[int],crops:[[x0,y0,x1,y1]],reference?: "file [input]"}: each variant (ops on a copy) x seed; returns a contact sheet (reference = first cell), 1:1 crop sheet, per-run elapsed_s/files. <=24 runs, wait=True; crops <=512px.

LONG RENDERS: a timeout cancels your wait, not the job. wait=False, front=False, poll get_run_status(prompt_id) to success/error/partial, then save_output; manage_queue(status).draftsman_submitted keeps prompt_ids.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
waitNo
frontNo
sweepNo
save_dirNo
roll_seedsNo
workflow_idYes
allow_invalidNo
confirm_spendNo
return_previewNo
timeout_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.19.0
    • addedInput schema / properties / sweep
      Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
  2. Changed10 schema fields changedv0.15.1
    • removedInput schema / properties / allow_invalid / title
      Removed value: -"Allow Invalid"
    • addedInput schema / properties / confirm_spend
      Added value: +{
+  "default": false,
+  "type": "boolean"
+}
    • addedInput schema / properties / front
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
    • removedInput schema / properties / return_preview / title
      Removed value: -"Return Preview"
    • addedInput schema / properties / roll_seeds
      Added value: +{
+  "default": true,
+  "type": "boolean"
+}
    • removedInput schema / properties / save_dir / title
      Removed value: -"Save Dir"
    • removedInput schema / properties / timeout_seconds / title
      Removed value: -"Timeout Seconds"
    • removedInput schema / properties / wait / title
      Removed value: -"Wait"
    • removedInput schema / properties / workflow_id / title
      Removed value: -"Workflow Id"
    • removedInput schema / title
      Removed value: -"run_workflowArguments"
  3. First observedv0.2.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only say non-read-only, non-destructive, open-world; the description adds substantial context beyond that: spend gating on partner/API nodes, the {status: queue_busy} refusal behavior, the fact that a timeout cancels the wait but not the job, seed re-rolling persistence, and output relocation requiring wait=True. This is exactly the extra behavioral layer the annotations cannot carry.

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 contract, then organized by parameter/topic; nearly every sentence earns its place. It is dense and telegraphic, and the sweep and LONG RENDERS blocks are slightly hard to parse on first read, but there is little genuine waste.

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 10-parameter tool with no output schema and no annotation detail, the description covers return shapes, failure modes, queueing, spend, and long-run recovery. An agent has everything needed to invoke and recover from it correctly.

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 must carry the full burden, and it does: it explains wait, front (three-valued semantics with the queue_busy case), sweep (its variant/seed/crop sub-structure and limits), save_dir, roll_seeds, allow_invalid, confirm_spend, return_preview, and timeout behavior. Only workflow_id is left implicit, which is reasonable.

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?

States a specific verb+resource ('Queue the workflow and (by default) wait for completion') and immediately enumerates what comes back (status, node errors, file refs, data_outputs, preview thumbnail). It is clearly distinguishable from siblings like get_run_status, save_output, and manage_queue, which it names as downstream steps.

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?

Explicit when-to-use guidance throughout: wait=False when you want to poll, return_preview=False for text-only callers, allow_invalid for bypassing local validation, confirm_spend only after the partner agrees, and a full 'LONG RENDERS' recipe naming get_run_status and save_output. It also routes the user-choice case via front=None.

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