Yumil Prompt Parser

The idea here is sneaky and kind of great: keep your prompt text, the reference images it needs, and the per-image settings (ControlNet strength, IPAdapter mode, whatever) all inside one prompt string. Yumil Prompt Parser is what turns that bundled string back into its parts.

This exists because of how Yumil MPM works. Your prompt library stores plain text - including text with a little structured markup in it. The markup format is:

###_Path(...).Value(...).Text(...)_###

Each element is optional, and you can chain them in any order. Path(img0.png,img1.png) embeds file paths (not just images - anything path-shaped). Value(strength=0.8,mode=ipadapter) carries comma-separated key=value parameters. Text(a beautiful girl) is the actual prompt text for that block. So one category in MPM can describe an entire image-conditioned generation: load these two references, apply an IPAdapter at 0.8, and generate this. That's the whole point - the parser lets MPM's text-only library carry what would otherwise take a dozen graph wires.

How it parses

The parser scans for ###_..._### blocks, then inside each block it walks the .Path(...), .Value(...), .Text(...) chain methods, tracking bracket depth so a Path(...) whose argument contains parentheses still parses correctly. It's the same bracket-depth logic MPM's own Category Identifier uses, so the two ends of the pipeline agree on the format.

Then it produces three outputs:

• clean_text - the prompt with blocks handled. Blocks that had a Text(...) get replaced by that text; blocks without one get removed entirely. Leftover comma and whitespace artifacts are cleaned up, so thing, ###_Path(img.png)_###, other doesn't leave you with doubled commas.
• block_count - how many blocks it found. Handy for sanity-checking that MPM actually included what you expected.
• PARSED_DATA - the structured payload, serialized to JSON. This is the output that feeds the rest of the pack: Yumil Block Selector picks a single block out of it, and from there paths flow to Yumil Image Loader and settings to Yumil Value Reader.

What you'd actually use it for

The README points at three real cases, and they map to the example workflows it ships:

• Extract embedded reference image paths. A stored prompt like ###_Path(girl.png).Text(portrait of a girl)_### loads girl.png as a reference through the loader chain instead of you hunting for it in ComfyUI's input folder.
• Pass ControlNet / IPAdapter parameters through the workflow. Value(mode=ipadapter) becomes a per-block setting you read out with Yumil Value Reader, so one stored prompt carries both the reference and how strongly it should be applied.
• Regional prompting. The linked regional-prompt workflow combines Attention Couple with per-region prompts from MPM categories - the parser is what turns each region's stored text into something a couple node can consume. (There's a detailed writeup on CivitAI the author links from the README.)

The single prompt input is multiline and does exactly what it says: paste or wire in the text. If there are no blocks at all, clean_text is just your prompt unchanged and PARSED_DATA is an empty list - so the node is safe to drop into a workflow that only sometimes uses the markup.

Installing and a note on the format

It installs as part of the pack - ComfyUI Manager search for comfyui-yumil-mpm, or:

cd ComfyUI/custom_nodes
git clone https://github.com/maigonia/comfyui-yumil-mpm.git
cd comfyui-yumil-mpm
pip install -r requirements.txt

Then restart. The only dependency is requests; the parser itself is pure Python, no models.

One gotcha to internalize: blocks are found by literal markers, so a prompt that types ###_ in normal prose will be read as the start of a block. Keep the markup reserved for actual blocks and you're fine. And when blocks have no Text(...), they vanish from clean_text entirely - that's a feature (paths shouldn't leak into the CLIP encoder), but it surprises people the first time they look at the clean output and their reference path is gone. It's supposed to be.