Workflow Tool

This is the node that turns "LLM chatbot in ComfyUI" into "LLM agent that can actually go do things in ComfyUI." Workflow Tool doesn't run a workflow itself - it packages other saved workflows into something an LLM can decide to call, the same way you'd give it a web search or a calculator. That's a meaningfully different capability than a normal chatbot node: instead of the model just talking about generating an image, it can trigger the actual image-generation graph, look at the result conceptually, and decide what to do next.

The mechanism

Under the hood this is function calling, ComfyUI-flavored. Modern LLM APIs let you hand the model a list of "tools" - each with a name and a description of when to use it - and the model responds with a request to invoke one when it judges that appropriate, instead of just generating text. Workflow Tool builds exactly that kind of tool description, except each "tool" is a .json workflow file sitting in this pack's workflow/ folder (or wherever you point it), so the agent can trigger a whole separate ComfyUI graph as one of its available actions.

That's why the two required fields are a matched pair. workflow_name takes a comma-separated list of workflow filenames - the default example is 写诗.json,draw.json ("write a poem" and "draw"), which tells you the intended pattern: one entry per callable workflow. workflow_description is the parallel comma-separated list of plain-language descriptions, one per workflow, explaining to the model what each one does and when to reach for it - the pack's own default pairs "写诗.json is a tool that generates a poem based on user input" with "draw.json is a tool that generates images based on user prompt." The LLM never sees the JSON graph itself; it only sees these descriptions, so writing them clearly is the actual skill here - vague descriptions get you a model that either never calls the tool or calls the wrong one.

is_enable is the standard kill switch this pack uses across most of its tool nodes - flip it off to remove the tool from the agent's available set without deleting the node from your graph. The single output, tool, is a STRING that wires into an LLM/agent node's tool-list input alongside whatever other tools you're offering (web search, GitHub, Wikipedia - this pack ships all of them as the same kind of pluggable STRING).

Where it fits

This is the node behind the "radial and ring agent-agent interaction" and "one-stop LLM + ComfyUI workflow" claims the pack's README makes. Instead of chaining nodes manually for every possible path, you build a handful of specialized workflows once, expose them as tools, and let the agent pick which one to run based on what the user actually asked for. It's the closest thing this pack has to a real autonomous-agent primitive, as opposed to a single scripted chain.

Installing it

Same as every node in this pack - it's not a standalone install.

• ComfyUI Manager: search "comfyui_LLM_party", install, restart.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/heshengtao/comfyui_LLM_party, then pip install -r requirements.txt in your ComfyUI environment, restart.

You don't need any of the heavier local-model dependencies (llama-cpp-python, transformers) just to use Workflow Tool - it's a lightweight text-building node - but they'll get installed anyway as part of the shared requirements.txt unless you set fast_installed = True in the pack's config.ini to skip the GGUF-related install path.

Common issues

The failure mode to expect isn't an error message - it's silence. If the model never calls the workflow you set up, the description text is almost always the culprit; the LLM has nothing else to go on when deciding whether a request matches a tool, so a description that's too generic ("does image stuff") loses to a more specific one on a different tool, or just gets ignored. Write the description the way you'd explain the workflow to a coworker who's never seen it: what it's for, and roughly what kind of request should trigger it.

Keep the filename list and the description list in the same order and the same count - the pack pairs them positionally by comma-separated index, so a mismatched count between workflow_name and workflow_description means at least one workflow ends up undocumented (or one description points at the wrong file). Also double-check the referenced .json files actually exist wherever this node expects to find them; a typo'd filename fails quietly rather than with a loud error at graph-build time.