Overview

Bridge an OpenClaw agent to a running ComfyUI instance by POSTing arbitrary workflow JSON to the /run endpoint and returning the resulting image URL or base64 data.

Key Advantages

1.Simple, thin wrapper around ComfyUI’s HTTP /run endpoint with minimal overhead.

2.Environment-based configuration of host, port, and optional basic-auth credentials (.env supported).

3.Generic workflow JSON support, allowing use with any ComfyUI graph without code changes.

4.Returns raw JSON from ComfyUI, preserving all response fields for downstream handling.

5.Suitable for local or LAN-hosted ComfyUI setups where direct HTTP access is permitted.

Use Cases

Triggering image generation from an agent using pre-defined ComfyUI workflows (e.g., text-to-image, image-to-image).
Automating batch or programmatic image generation via ComfyUI from within an OpenClaw pipeline.
Integrating chat or task agents with a local ComfyUI node for on-demand illustration or concept art.
Running parameterized workflows where the agent populates node parameters in the JSON workflow before submission.
Prototyping and testing new ComfyUI graphs by sending workflow JSON from an agent without writing custom HTTP code.

Evaluation Scores

6.7

/ 10

Reliability

6.5

Functionality

6.5

Usability

6.5

Safety

6.0

Performance

8.5

Compatibility

7.5

Based on 1 evaluation · Latest: 3/19/2026

Download Trend

Loading...

Evaluation History (1)

6.7/103/19/2026win32-x64

▼

OS: win32-x64LLM: z-ai/glm-5

**Quick judgment**: This is a lean, focused integration skill that simply forwards JSON workflows to a running ComfyUI instance and returns the raw response (including image URL or base64). It’s well-suited when you already operate ComfyUI, understand its workflow format, and just need an agent-accessible bridge. **Strengths** - Minimal complexity and overhead: essentially a direct HTTP client for ComfyUI’s `/run` endpoint. - Flexible: accepts any valid ComfyUI workflow JSON, so it doesn’t constrain how you design graphs. - Straightforward configuration via environment variables or `.env` (host, port, optional basic auth). **Key risks / limitations** - **Hard dependency on an external ComfyUI server**: if the server is down, misconfigured, or the `/run` endpoint changes, the skill becomes unusable. - **No workflow validation or schema checking**: invalid workflows or parameter mistakes will only surface as remote errors from ComfyUI. - **Limited robustness**: documentation suggests a single POST with no mention of retries, detailed error handling, or timeouts; large or slow generations may fail poorly. - **Security considerations**: relies solely on optional basic auth; if the ComfyUI instance is exposed beyond a trusted network, you must harden it yourself (firewalls, auth, TLS via reverse proxy, etc.). - **Safety and content moderation are entirely delegated to ComfyUI and the underlying model**: this skill does not add any filtering or guardrails. **Recommended scenarios** - You run ComfyUI locally or on a secured LAN and want an OpenClaw agent to trigger image workflows. - You already maintain, test, and update ComfyUI graphs and just want a thin integration layer rather than a complex orchestration tool. - You’re building automation or prototyping flows where the agent can construct or modify workflow JSON dynamically. **Less suitable when** - You need strong safety controls, content filtering, or policy enforcement around generated images at the skill level. - You require rich job management (queues, progress tracking, cancellation, retries) or workflow abstraction beyond raw JSON. - You don’t control the ComfyUI server environment or cannot reliably expose `/run` to the skill runtime.

Comfyui anfrage