Schema Boolean Parameter

Every agent-run workflow has a few yes/no knobs: run the hires fix or not, use the refiner or not, enable face restoration or not. ComfyUI can already do that with a plain toggle - but a plain toggle doesn't tell an agent what it's for, what it defaults to, or whether it's mandatory. That's the niche this node fills: a BOOLEAN parameter that doubles as a machine-readable field declaration.

It's the simplest of the eight nodes in ComfyUI_SchemaNodes, and honestly that's the appeal. There's almost nothing to learn, so it's the one to start with if you want to see how the pack's contract pattern works before tackling the string or image nodes.

The inputs that matter

• name - the stable identifier your tool will expose (use_refiner, not "toggle").
• io_kind - input means the agent must (or may) supply the value; output means the workflow is declaring a boolean result, like "was the image upscaled" or "did the safety check pass."
• description - one sentence written for a machine: "Enable the second-pass refiner for higher detail." This is what your agent reads when deciding whether to flip the switch.
• required - set this true only if the agent has to answer. A boolean with a sane default and required=false is friendlier for the agent; it can just omit it and get the default.
• default - the fallback (false by default). This is what flows through when nothing is wired in.
• value_in (BOOLEAN, forced input) - the override. Wire another node's boolean into it and it beats default. This is how a tool injects the agent's answer at runtime.

That's it. No min/max, no pattern, no options - booleans don't need them. The only thing to get right is the description.

How it works

On execution it resolves value = value_in or default, coerces to bool, and emits it as a BOOLEAN on the value output. Downstream that plugs straight into anything expecting a boolean - a KSampler's refiner toggle, a conditional gate, a ConditioningSetTimestepRange-style switch.

The schema side is where the magic lives: your tool parses the workflow JSON, reads the widget values, and gets a clean {"name": "use_refiner", "type": "boolean", "default": true, "required": false, "description": "..."} declaration. An LLM can act on that description, which is precisely the agent-drive-the-workflow use case the pack is built for. Note the README still describes a SCHEMA_FIELD output that the current code removed - the metadata lives in the widget values now, not in a runtime output, so don't go hunting for a second output.

Installing it

One pack install covers all eight nodes.

cd ComfyUI/custom_nodes
git clone https://github.com/Liquid-XO/ComfyUI_SchemaNodes

Restart ComfyUI, or use ComfyUI Manager (search "ComfyUI SchemaNodes"). No pip dependencies, no models to download, no keys. It's about as low-risk a custom node install as exists.

Common gotchas

• required vs default is a real design decision, not trivia. Mark a boolean required=true and the agent must answer even when the default is fine - that's friction you're adding. Reserve required=true for toggles where a wrong default has real consequences (like a "delete outputs" flag).
• The node won't validate anything at runtime. The required flag is metadata for the tooling, same as every other declaration in this pack. If you wire garbage into value_in, the node will happily coerce it to a bool - Python truthiness and all. Your tool is the enforcement point.
• Input/output coloring. The pack's frontend extension prefixes titles with [IN]/[OUT] and colors the nodes (green in, blue out). Purely cosmetic, but it does make a wall of toggles scannable at a glance.