ComfyUI Skills for OpenClaw: a CLI layer between agents and ComfyUI graphs

The problem: agents editing ComfyUI graphs they should not touch

A ComfyUI workflow is a graph. Node ids, widget values, links, and loader paths all sit in the same JSON document, and any agent that can write to that document can change anything in it. That is a poor fit for a chat-driven task like "generate four variations of this prompt at 1024x1024". The agent has to locate the right node, guess at the widget order, and hope the sampler settings survive the edit. ComfyUI Skills for OpenClaw takes the opposite position. The README describes it as an agent-friendly bridge that turns ComfyUI workflows into callable skills, and the design goal is stated plainly: instead of asking an agent to manipulate raw ComfyUI graphs, each workflow gets a clean, controlled interface through a CLI and schema-based parameter mapping. The audience follows from that. It is for people who already have working ComfyUI workflows and want them callable from OpenClaw, Hermes Agent, Codex, Claude Code, or any agent that can run shell commands. It is not for people who want an agent to build workflows. The project states that its CLI is the primary interface and that the Web UI is optional, for configuration and testing only. If you are looking for an autonomous graph author, this is the wrong layer.

Schema-based parameter mapping is the whole mechanism

The central idea is a mapping layer generated at import time. You import a workflow JSON file, the project auto-detects the format, and it produces the mapping needed for agent use. That mapping is where the control lives: it exposes only the fields you want the agent to control, each with an alias, a type, and a description. Everything else in the graph becomes fixed. A prompt node's text field might become a string parameter called prompt. A seed might become an integer parameter. The checkpoint loader path, the sampler, the resolution, and every other widget stay as they were in the exported file, outside the agent's reach. This is a narrower contract than handing over the graph, and the narrowing is the point. It also means the quality of the skill is bounded by the quality of the import: a workflow with values baked into unusual places will produce a mapping that exposes the wrong things, and correcting that is manual work in the configuration layer. The README does not describe an automatic heuristic for choosing which fields to expose, so treat the generated mapping as a draft to review rather than a finished interface.

CLI and MCP are split by job, not stacked

The project is explicit that it is complementary to the official local Comfy MCP rather than a replacement, and it draws a line between them. Use comfyui-skill for registered workflows, repeated execution, batch jobs, uploads, and history. Use the official local Comfy MCP when the agent needs to discover current templates, nodes, or models, validate a raw workflow, adapt a template, or manage the local ComfyUI lifecycle. That division is coherent: the CLI is a fast path for known work, the MCP is the discovery and validation path for work the agent has not seen before. The integration has two modes. If the agent host already exposes the official MCP tools, the skill calls them directly. If the host can only run shell commands, the repository ships a bridge script, and the README gives these examples:

python ./scripts/comfy_mcp.py probe python ./scripts/comfy_mcp.py call search_templates --arguments '{"query":"upscale"}'

The probe subcommand is the interesting one, because it answers whether the MCP side is reachable before an agent commits to a plan that depends on it. The documentation points to a separate page on the project's GitHub Pages site for setup, routing, and safety boundaries, which is where the details you would need before wiring this into a host live.

Getting it running: prerequisites and the first import

The requirements are short. Python 3.10 or newer, a running ComfyUI server, and an exported workflow in ComfyUI API format if you want to test execution immediately. The API format detail matters and is easy to miss: the normal ComfyUI save produces a UI-format graph, and the project asks for the API export instead. The quick start begins by cloning the repository into the directory that matches your agent environment, with separate instructions for OpenClaw and the other hosts. The README lists the CLI, the Web UI, and multi-server management as its own anchored sections, so the configuration surface for those lives there rather than in the quick start. What the material does not give is the full set of config keys or the exact registration command for a workflow. The README is truncated before those appear. If you need to know the precise flag names before committing, read the CLI section of the repository README or the GitHub Pages documentation rather than guessing from the feature table.

Multi-server routing and dependency checks are the operational features

Two capabilities matter more than the rest once you move past a single machine. The first is multi-server routing: the project manages local and remote ComfyUI servers under one namespace and routes jobs to the right machine. For anyone running a laptop ComfyUI instance alongside a rented GPU box, that removes the need for separate agent configurations per host. The second is dependency management. The CLI checks for missing nodes and models before execution and can install supported dependencies through the CLI. Pre-flight checking is the right default here, because a ComfyUI job that fails on a missing custom node usually fails deep in the queue with an unhelpful error. The word supported in that sentence is doing real work: installation is limited to whatever the project knows how to install, so a private or unusually packaged node pack will still be a manual fix. The README does not enumerate which dependency types are covered, and that gap is worth closing against your own node inventory before you rely on it.

Where this is the wrong tool

The limitation is structural, not a bug. By design, the agent cannot see or modify the parts of the graph that were not exposed during import. That is what makes execution predictable, and it is also what makes the project useless for exploratory work. If a task requires changing the sampler, swapping the checkpoint, inserting an upscale stage, or re-wiring a controlnet, the agent has no path to do it through the skill. The project's own answer is to send that work to the official local Comfy MCP, which handles template discovery, node and model discovery, and raw-workflow validation. So the honest framing is that you need both, and the skill alone will not cover an agent that is expected to reason about unfamiliar workflows. There is a second constraint worth naming. The mapping is generated from a specific exported JSON file, so it is tied to that file's structure. Re-export the workflow after changing it in the ComfyUI editor and the mapping may no longer line up with the nodes it referenced. Nothing in the supplied material describes a migration or re-validation step for that case, so plan on re-importing and re-checking the exposed fields yourself.

Compared with calling ComfyUI directly or through the official MCP

The realistic alternative is not another skill framework. It is driving ComfyUI through the official local Comfy MCP alone, or posting workflow JSON to the ComfyUI HTTP API from a script. The MCP route gives the agent live discovery of templates, nodes, and models, plus raw-workflow validation and lifecycle management, which is broader than anything the skill offers. What it does not give you is a per-workflow contract with named, typed parameters and a fixed blast radius. An agent working through raw graph JSON has to be trusted with the whole document every time. The skill trades that breadth for a smaller surface: registered workflows, repeated execution, batch jobs, uploads, and history, all through one CLI. If your agents run the same handful of workflows many times a day, the narrower surface is the better fit and the faster path. If your agents are mostly exploring what a ComfyUI install can do, the MCP alone covers more ground and the skill adds a registration step you will not use.

Maintenance cost and the MIT licence

The project is MIT licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive arrangement, and it is the reason this kind of glue layer is easy to vendor into an internal agent stack. Nothing here is legal advice; read the LICENSE file in the repository for the actual terms. On maintenance, the release history is thin: v0.1.0 is listed as the first public release, dated 2026-03-11, and the repository was last pushed on 2026-08-26. That is a single tagged release with subsequent commits, which tells you the project is active but has not yet settled into a versioned cadence. The upgrade surface you own is the mapping layer. Every time you import a workflow you create configuration that a future CLI version might read differently, and the material does not describe a compatibility guarantee across releases. Pin the version you install, keep your exported workflow JSON under version control alongside the generated mappings, and you can rebuild the layer from source if a release changes behaviour. Without that, an upgrade becomes archaeology.

Editorial conclusion

Adopt it if you already own exported ComfyUI workflows and want agents to call them through a fixed parameter surface instead of editing graph JSON. Do not adopt it if your agents need to author new graphs, discover nodes at runtime, or drive the ComfyUI lifecycle, because those jobs belong to the official local Comfy MCP in the project's own split. Before installing, verify that your ComfyUI server is reachable, that your workflow is exported in API format, and that every custom node and model it references is present, since the CLI checks dependencies before execution and will stop on what is missing.

Official sources

1. HuangYuChuh/ComfyUI_Skills_OpenClaw on GitHub
2. License: MIT
3. Project website
4. README
5. Releases