Text to parameters
Parse an LLM's JSON reply into real structured data
- json_data
Ask an LLM to return structured data and you'll get it back as text that looks like JSON - because it is JSON, just wrapped in a plain STRING output because that's the only shape a text model naturally produces. text2parameters closes that gap: it parses the text and hands you back a real DICT object, the type other nodes in this pack (and ComfyUI generally) actually expect if they need to read specific named fields rather than treat everything as one undifferentiated blob of text.
This matters any time you want a single LLM call to configure multiple things at once. Instead of parsing five separate values out of five separate prompts, you ask the model once for a JSON object with five keys, and text2parameters turns that single string into something the rest of your graph can pick fields off of.
Inputs and outputs that matter
text- the raw text to parse. It's flaggedmultiline, meaning the node gives you a proper multi-line text box in the UI rather than a single-line field - sensible, since JSON responses tend to be long.json_data- the single output, aDICT.
Installing it
Search comfyui_LLM_party in ComfyUI Manager and install, or clone it directly:
cd ComfyUI/custom_nodes
git clone https://github.com/heshengtao/comfyui_LLM_party
pip install -r requirements.txt inside your ComfyUI Python environment, then restart. No model or API key needed for this specific node - it's a parsing step - but it's bundled inside the full pack, whose overall dependency list is large. The README's only_api branch is the leaner install if you only want API-based LLM calling.
Common issues
The single biggest failure mode is the model not returning clean JSON. LLMs love to be helpful about it - wrapping the object in a fenced code block, adding a sentence of commentary before or after ("Here's the JSON you asked for:"), or explaining its reasoning first. Any of that breaks a strict parse. The fix is almost always upstream, in the prompt: tell the model explicitly to respond with raw JSON only, nothing else - no code fences, no preamble. Lowering the temperature on that particular call also helps, since it cuts down on the model "editorializing" around the data it was asked to return.
Once parsing succeeds, remember json_data's actual shape is whatever the model decided to send - if your prompt didn't pin down exact key names, the model is free to vary them slightly between runs, and anything downstream reading a specific key will break silently if that key isn't there this time. Being explicit about the exact JSON schema you want in your prompt (key names, types, an example) pays off far more here than trying to make this node itself more forgiving after the fact.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| text | STRING | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| json_data | DICT | — |