ComfyUI Skills for OpenClaw: turning ComfyUI workflows into agent-callable skills

The gap between a ComfyUI graph and an agent that wants to call it

A ComfyUI workflow, exported, is a graph of nodes with wires between them. An agent that is handed that file has to reason about node identifiers, input slots and latent shapes before it can change anything. The README frames the project as an answer to exactly that: instead of asking an agent to manipulate raw ComfyUI graphs, it gives each workflow a controlled interface built on a CLI plus schema-based parameter mapping.

The audience is narrow and stated plainly. OpenClaw, Hermes Agent, Codex and Claude Code users; people who already own exported ComfyUI workflows and want to reuse them without exposing the whole graph; multi-machine setups that want one namespace across local and remote ComfyUI servers. If you are a solo user who clicks Run in the ComfyUI web interface, this adds a layer you do not need.

Schema mapping, multi-server routing and the dependency check

The mechanism has three visible parts. First, workflow import: the project reads workflow JSON files, auto-detects the format, and generates the mapping layer that agent calls go through. Second, parameter mapping: the schema decides which fields the agent may control, and gives each one an alias, a type and a description. Everything else in the graph stays fixed. That is the whole point of the design, and it is also its main cost, because the mapping has to be authored and kept in sync with the workflow.

Third, execution. A request is routed to a ComfyUI server by name, so local and remote machines sit under one namespace. Before a job runs, the project checks for missing nodes and models and can install supported dependencies through the CLI. That check is the part most worth understanding, because a workflow that imports successfully can still fail at run time when a custom node pack is absent on the target machine.

The README draws a line between this CLI and the official local Comfy MCP. The CLI is for registered workflows, repeated execution, batch jobs, uploads and history. The MCP side is for live discovery of templates, nodes and models, raw-workflow validation, template adaptation, and managing the local ComfyUI lifecycle. The project calls them two tools for different jobs rather than replacements for each other, and says that when the agent host already exposes the official MCP tools, the skill calls them directly.

Installing ComfyUI Skills and running a first workflow

The README lists three prerequisites before anything else: Python 3.10 or newer, a running ComfyUI server, and an exported workflow in ComfyUI API format if you want to test execution immediately. Note the format. A workflow saved in the UI layout is not the same file as an API-format export, and the quick start asks for the latter.

The repository ships a requirements.txt with the runtime dependencies, so the install path is a virtual environment plus pip. The README's quick start then branches by agent environment and asks you to clone the project into the directory that matches yours. The repository also carries config.example.json at the top level, which is the file to copy when you configure servers.

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

After that, the workflow goes through the import and registration step described in the quick start, and the workflow becomes callable by name. The project also ships an update.sh at the repository root for pulling changes.

If your agent host has no MCP tools available and can only run shell commands, the README points at an included bridge. The probe subcommand reports what the MCP side exposes, and call invokes a named tool with JSON arguments. The example given is a template search for the term upscale.

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

Expect probe to tell you whether the MCP path is reachable at all. If it is not, the CLI still works for registered workflows, and the discovery features are simply unavailable to that host.

Where the mapping layer becomes the maintenance burden

The schema is the feature and the liability. Every workflow you register needs its own set of exposed parameters, aliases, types and descriptions, and the README does not describe any automatic regeneration when the upstream workflow changes. Edit the graph in ComfyUI, re-export it, and the mapping you wrote against the old node layout is now something you have to reconcile by hand. For a handful of stable workflows that is fine. For a library that changes weekly, it is a chore that sits entirely with you.

The dependency check has a similar boundary. The README says the project can install supported dependencies, which implies a set of dependencies it supports and, by extension, ones it does not. Custom node packs outside that set remain your problem, and the failure surfaces at execution time on the target server, not at import time.

There is also a host requirement that is easy to skim past. The project works with agents that can run shell commands. An agent platform that only accepts HTTP tool calls and cannot execute a local process has no path to the CLI, and the MCP bridge does not change that, because the bridge is itself a script you run.

Finally, treat this as the wrong tool if you want an agent to compose novel graphs. The design deliberately hides the graph. An agent that needs to build a new workflow from nodes is better served by the raw-workflow validation and template adaptation the README assigns to the official local Comfy MCP.

How this differs from pointing an agent straight at the official Comfy MCP

The obvious alternative is to skip this project and give the agent the official local Comfy MCP alone. That is a real option, and the README does not pretend otherwise: it explicitly describes the two as complementary and says the skill calls the MCP tools directly when the host already exposes them.

The difference is in what each side is good at. The MCP interface is a live runtime surface. It discovers the templates, nodes and models that exist on the machine right now, validates a raw workflow, adapts a template, and manages the ComfyUI lifecycle. That is the right interface when the agent is exploring. It is a poor fit for the tenth identical upscale run of the day, because nothing about it is pinned to a fixed parameter set.

The CLI is the opposite. It is fast and repeatable precisely because the parameter surface was frozen in advance, with batch jobs, uploads and history attached. The trade is flexibility for predictability. A team running a small set of production workflows from chat gets more value from the frozen surface; a team whose agent needs to inspect what is installed gets more from the MCP. Running both, as the README intends, means the agent discovers through MCP and executes through the CLI.

Licence, release history and what an upgrade costs

The repository is MIT licensed, with the LICENSE file at the root. MIT is permissive: it allows use, modification and redistribution provided the copyright notice and licence text are kept. That is a statement about the licence text, not advice about your situation, and if you redistribute the project inside a product you should read the file yourself rather than take this summary as sufficient.

On maintenance, the facts are these. The repository is not archived. The last push was on 2026-08-26. The only release listed is v0.1.0, dated 2026-03-11 and labelled First public release. That combination tells you two things worth weighing. Work has continued on the main branch since the release, and there is no second tagged version to pin against. If you want a stable reference point, v0.1.0 is the only one the repository offers.

The upgrade cost is dominated by the schema layer rather than by the code. Because the mapping is authored per workflow, a change in the project's import format or parameter conventions is something you discover when a registered workflow stops behaving, not when you pull. The README does not document a rollback procedure, and the changelog is the place to look before running update.sh. Pin to v0.1.0 or to a commit you have verified if you need reproducibility.

Editorial conclusion

Adopt it if you already own exported ComfyUI workflows and want them callable from an agent host that can run shell commands, and if you are willing to keep the CLI and the official local Comfy MCP in separate roles. Do not adopt it if you have no running ComfyUI server, no API-format workflow, or no appetite for maintaining a mapping layer per workflow. Before committing, verify that your workflow imports cleanly, that the dependency check reports your custom nodes and models as present, and that your agent host can invoke the CLI or the included comfy_mcp.py bridge.

Frequently asked questions

Official sources

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