UpdateNodeCatalog

Every other node in this pack has an unspoken dependency, and it's this one. UpdateNodeCatalog scans your ComfyUI installation - every native node and every custom node pack you've got - and writes out the catalog files (node_list.json and node_info.json) that NodeValidator and WorkflowBuilder use to check names and fetch input/output signatures. It's the only node here with no model, no LLM, and no GPU requirement. Run it once when you install the pack, re-run it whenever your node inventory changes, and otherwise forget it exists. It's the housekeeping that makes the fancy parts work.

The README is explicit about this: run it before you do anything else. If you fire up the pipeline without a catalog, validation has nothing to check against and the builder can't look up node signatures, which is how you get "node type not found" errors from a supposedly complete pipeline.

Inputs and outputs

Two inputs, both with sane defaults:

• catalog_directory - where the catalog files get written. Defaults to catalog, i.e. a catalog/ folder inside the custom node's own directory. You almost never need to change this; the other nodes default to the same location.
• force_update - false by default. If the catalog files already exist, the node skips the scan to save startup time. Flip it to true when you want to force a rebuild - say, after ComfyUI updated its core nodes, or when you suspect the catalog is stale.

Outputs: status (a JSON string telling you whether the update succeeded) and node_count (how many node types it found - useful as a sanity check that the scan actually saw your custom packs). Both are just informational; there's nothing to wire on to.

What it actually does

Under the hood it reads ComfyUI's node registry, which is interesting in its own right: the pack supports both the classic V1 node API (INPUT_TYPES / RETURN_TYPES on a node class) and the newer V3 schema API that this pack itself is built on. It captures each node's name, display name, inputs, outputs, category, description, and output-node flags, then stores the results - node metadata in a JSON list, full input/output details in a TinyDB file. That metadata is the entire knowledge base for the validator's semantic search and the builder's socket matching.

When to run it

The rule of thumb is in the tooltip and the README: after installing new custom nodes or updating ComfyUI. The workflow generation model is frozen at its training cutoff and can't learn about new packs - the catalog is the pack's only way to know what's actually on your machine. If a generated workflow keeps referencing nodes you don't have, or the validator keeps "fixing" names to nodes that clearly exist in your install, run this with force_update on before you go any deeper. If node_count looks suspiciously low (like it only sees core ComfyUI nodes), that's your first clue the scan missed your custom packs - usually a restart or a check of your custom_nodes folder resolves it.

Install is the pack standard: clone into custom_nodes, pip install -r requirements.txt, restart. This node specifically needs no models and no llama-cpp-python - it's the one part of the pack that just runs, which makes it a good first test that your install is sane before you download 15 GB of models.