Schema String Parameter

This is the workhorse of the SchemaNodes pack. If you're building a ComfyUI workflow that an agent is going to drive like an API, the prompt is the first thing that agent needs to set - and this node is how you declare that text field so a machine can read the declaration. Wire its value output into a CLIPTextEncode positive or negative prompt input, and you've turned one of the most free-form parts of ComfyUI into a typed, documented, machine-readable contract.

The whole idea behind ComfyUI_SchemaNodes is that a workflow JSON is a sea of nodes with no obvious entry or exit points. These parameter nodes label them. Every one of the eight nodes shares the same skeleton: name, io_kind (input or output), description, and required - plus type-specific fields. The string node gets the most of those fields, because text is the thing agents fiddle with most.

The inputs that matter

• name - the field name your tool will expose. Make it a stable, snake_case-ish identifier (positive_prompt, not "the good one"). Your agent's code will reference it.
• description - write this like a docstring for a machine: "The prompt for the main subject. Can include quality tags." Your parser reads it and the agent uses it to decide what to fill in. A blank description defeats half the point.
• io_kind - input means the agent must provide this before running; output means this is something the workflow hands back.
• default, multiline, placeholder - the fallback value, whether the text box is multiline, and the UI hint.
• min_length, max_length, pattern - text constraints that become minLength, maxLength, and pattern in the generated JSON Schema. Set to 0 or empty, they're simply omitted, so don't worry about the defaults.

There's also an optional value_in (STRING, forced input). If you wire something into it, that value wins over default; leave it unplugged and the default flows through. That's the override mechanism the whole pack uses, and it's how a tool injects the agent's answer without touching your canvas.

How it works

At execution the node resolves value = value_in or default, and hands it down the graph as a plain STRING - nothing exotic. What's actually interesting is what the README says it does, because the README is stale. It still claims each node emits a SCHEMA_FIELD metadata object alongside the value; the current code (commit 8e5676d, "Remove SCHEMA_FIELD output from all parameter nodes") removed that. You get one typed value output. The schema metadata lives in the node's widget values inside the workflow JSON, which is where your tool should read it from. Don't go hunting for a second output that isn't there.

One more behavior worth knowing: set io_kind to output and the node will also save the resolved string to a .txt file in ComfyUI's output folder, named after name (e.g. my_result_00001.txt). That's how an agent picks up a text result as a file rather than parsing your whole graph.

Installing it

Grab the pack once and you have all eight nodes; there's nothing per-node to install.

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

Restart ComfyUI, or install via ComfyUI Manager by searching "ComfyUI SchemaNodes". Good news for the paranoid: this pack has no pip dependencies and no model downloads - the pyproject.toml lists nothing to install, and the code only uses libraries ComfyUI already ships (torch, numpy, PIL). Nothing phones home, and there's no API key anywhere in this pack.

Common gotchas

• A blank description makes the field useless to an agent. The whole value of this node is the machine-readable contract; skip the description and you might as well use a plain primitive.
• Don't expose this to the internet unauthenticated. These nodes exist to make your workflow programmable, and ComfyUI's API is unauthenticated by default - anyone who can reach the port can execute arbitrary workflows. That's the security frame from the ecosystem docs, and it applies directly here.
• The [IN] / [OUT] title prefix on the node is cosmetic, added by the pack's frontend extension to color-code input vs output roles (green in, blue out). Ignore it if you see it; know that it's not part of the schema.