Skip to main content
Glama

run_workflow

Queue a ComfyUI workflow for execution, optionally wait for completion, and return status, node errors, output file references, data values, and a preview thumbnail.

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.

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]",freeze?:node_id}: each variant (ops on a copy) x seed; returns a contact sheet (reference = first cell), 1:1 crop sheets, per-run elapsed_s/files. <=24 runs, wait=True; crops <=512px or 0-1 floats.

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.

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>"
    },
    "name": "run_workflow"
  }
}

Input 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?

The description discloses behavior well beyond the sparse annotations: timeout only cancels the wait, not the job; queue_busy is returned when prompts are pending; save relocation requires wait=True or later save_output; and spend-gated partner/API nodes require explicit confirmation.

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?

The description is front-loaded and dense with useful information, appropriate for a complex 10-parameter tool. It could be more structured, but almost every sentence carries operational value rather than restating schema details.

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?

With no output schema and sparse annotations, the description compensates by documenting return shapes, failure behavior, preview behavior, sweep results, and long-render workflow. An agent has enough context to invoke the tool correctly without opening another source.

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?

Even with 0% schema description coverage across 10 parameters, the description explains the practical meaning of the non-obvious ones: wait, front, sweep, save_dir, roll_seeds, allow_invalid, confirm_spend, return_preview, and timeout behavior. workflow_id is only implicitly defined, but the overall parameter coverage is far above baseline.

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?

The description states a specific verb and resource: queue a workflow and optionally wait for completion. It immediately clarifies the returned data and distinguishes the polling path by naming get_run_status when wait=False.

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?

It gives explicit operational guidance: use wait=False plus get_run_status for long renders, use save_output afterward, and prove a workflow works before saving. It also explains when front=None should be used and when confirm_spend=True is appropriate.

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