External Prompt Requester

This is the node the whole pack exists for. Yumil MPM is a desktop prompt-management app - think a categorized library of your positive/negative/pose prompts, with its own On-Demand Generation. External Prompt Requester is how ComfyUI reaches over and asks it, "what should I draw today?", by category name. It doesn't call any cloud API and needs no key you type into ComfyUI - the whole conversation stays on localhost.

If you've ever kept your prompts in a spreadsheet or a .txt file and copied them into ComfyUI by hand, you already know the pain this removes. Wire the requester up, hit Run, and the current Positive / Negative / Pose prompts (or whatever categories you define) drop straight into your graph as ten plain text outputs. You manage the prompt text in MPM, where it belongs, and the workflow just consumes it.

How it actually works

Under the hood it's a small HTTP client. Each run it reads the MPM API key from ~/.mpm/api_key (or the MPM_API_KEY environment variable), then POSTs to http://127.0.0.1:19720/api/v1/generate asking for a fresh generation per category. That port matters: it's MPM's local API server, so MPM has to be running and have its API server enabled with a generated key. The key never lands in the node's widget, which is the right call - an API node that carries a credential is exactly the shape of the thing that has been weaponized in this ecosystem before, so keeping the secret out of the workflow file is a genuine plus.

Two behaviors worth knowing about. First, the node forces itself to re-run every time (its IS_CHANGED returns NaN), so each Run pulls fresh prompts instead of being skipped by the cache. Second, with newer MPM versions there's a queue-completion handshake: when MPM's finite generation queue finishes, the final prompts still flow into your workflow, the browser extension flips ComfyUI's Queue mode to manual (so nothing auto-reruns without you), and - if you've armed "Sleep PC after completion" - a same-origin route confirms completion only after the whole workflow, output nodes included, actually succeeded. Execution errors and interruptions report failure, so MPM won't put your PC to sleep mid-save. Older MPM versions just keep the old behavior: no handshake, no problem.

The inputs and outputs that matter

You only really set two things:

• prompt_1 … prompt_10 - the MPM category names to request. The first three default to Positive, Negative, Pose, which tells you how the author expects you to organize. Leave blanks for categories you don't need.
• timeout_seconds - how long to wait for MPM before giving up. Default 240 seconds (range 5–600). On-demand generation can take a while if MPM is mid-queue, so this is a "walk away" timeout, not a "should've answered by now" one.

The ten outputs are plain STRINGs, one per category, in the same order. Wire prompt_1 into a CLIP Text Encode for the positive and prompt_2 for the negative, or straight into one of this pack's other nodes (Yumil Prompt Parser, Yumil Lora Stripper) if your stored prompts carry <lora:...> tags or embedded file paths.

Installing it

This node needs the pack plus the app. Install the pack the usual way:

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

(Or just search comfyui-yumil-mpm in ComfyUI Manager and let it handle it.) Then restart ComfyUI. The only Python dependency is requests - no model files, nothing heavy. Separately, install and launch Yumil MPM, press the Demand button in its Generation panel to enable On-Demand Generation, and make sure the API server is on with a generated API key.

Where people get burned

The failure mode is quiet, which is the trap. If MPM isn't running, the API key is missing, or a request times out, the node returns empty strings and logs a message to the console - it doesn't error. Your sampler will happily run with a blank prompt and you'll get an image that looks nothing like what you wanted. If outputs come back empty, check three things in order: is MPM running, is the API server enabled, and does ~/.mpm/api_key exist? All three are checked silently on every run, so this is the first place to look when a previously-working workflow suddenly produces garbage.