Mepi Negative Prompt
The node that just holds what you don't want
- STRING
It's a string with a job to do
Let's be honest about what this node is: a string with a job to do. You type a negative prompt into the multiline box, Mepi Negative Prompt hands that exact text back out its STRING output, and you wire that into the negative input of a CLIP Text Encode node. That's the entire mechanism - the source is literally return (prompt,), and the output tooltip the author wrote is "Prompt for Negative."
So why does it exist at all? Because it's part of ComfyMepi, a small mobile frontend for ComfyUI by rhplus0831 (heavily inspired by chibi-client, per the README). A phone screen can't drag nodes around, so the mobile UI edits values inside a template workflow and resubmits the JSON. Every Mepi node is a slot the frontend writes into - this one is the "what do you not want" field. If you never open the mobile UI, you genuinely don't need it: ComfyUI's built-in CLIP Text Encode has the same negative input.
What you set
One input, one output. That's the whole story:
prompt(STRING, multiline) - your negative prompt text.STRINGoutput - labeled "Prompt for Negative." Wire it into the negative text input of CLIP Text Encode, next to the positive.
No weights, no conditionals, nothing to tune.
Install
Same story as the rest of the pack - trivial. Via ComfyUI Manager, open Manager → Install Custom Nodes, search ComfyMepi, install, restart. Or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/rhplus0831/ComfyMepi
Then restart ComfyUI. There's no requirements.txt and nothing to pip install - the nodes only use ComfyUI's own libraries. No model files to download either; it's pure plumbing. (The mobile UI itself shows up at http://<your-server>:8188/mepi if you want to see what these nodes are for.)
When "the negative isn't working" isn't the node's fault
Since this node just moves text, it can't protect you from the two ways negative prompts fail in the wild:
- On SD 1.5 / SDXL-lineage models, keep the negative short. Long keyword walls that contradict the positive prompt cause more trouble than they save. A classic starting point is
bad hands, extra fingers, mutated hands, poorly drawn hands, fused fingersplus a couple of quality terms. - On flow-matching / guidance-distilled models (Flux and friends), a negative prompt does nothing by default. Those architectures don't read the negative the way SD does. If you edit this node and the output doesn't budge, that's almost always why - not a broken node.
Troubleshooting
There is not much to break on a node whose entire body is one return statement. If images come out wrong, check the CLIP Text Encode wiring and the sampler, not this box. One honest caveat about the pack: it's a personal project with essentially no community footprint and light maintenance, so don't expect a lively bug tracker - if the node ever misbehaves, the fix is usually just doing the same thing with the core CLIP Text Encode node.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| prompt | STRING | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| STRING | STRING | Prompt for Negative. |