Serving Input Text

ServingInputText is the bridge between what a user types and what your workflow actually samples. It's the node you'll reach for first in any serving workflow: it grabs a string out of the incoming request and hands it to your graph as a plain text output. Everything else - images, numbers, routing - hangs off the fact that this one got the prompt into the pipeline.

How it works is refreshingly direct. When a user sends !generate 4k epic realism portrait --negative drawing to a Discord bot (or the equivalent on Telegram, HTTP, or WebSocket), the entry point node parses the message into named arguments. ServingInputText then looks up one of those argument names in the serving config and returns its value. The request's free text always lands in an argument called prompt, so the default argument setting of "prompt" is exactly what you want for the main prompt. Every --name value pair becomes another retrievable argument.

Inputs:

• argument - which argument to pull. Defaults to prompt. Set it to negative in the example above and you'd get "drawing" out the text port.
• default - what to return when the user didn't supply that argument. This is how you make arguments optional with sensible fallbacks.
• serving_config - the config from your entry point node.

The output is a single text string. Wire it into your CLIP Text Encode, a positive/negative conditioning, a prompt template, or anything else that eats a STRING.

There's a sneaky second use hiding in the README that's worth knowing about: because attachments are exposed as attachment_url_0, attachment_url_1, and so on in the config, you can set argument to attachment_url_0 and the node will hand you the URL of an attached image as text. The README suggests pairing that with a node like WAS Image Load to download and use the image - the direct-attachment input nodes (ServingInputImage) now do this for you with less ceremony, but if you're already running WAS, this trick means you don't need to change your stack.

Note the split personality: default is a multiline text box while argument is single-line. That's the author's way of saying "the default is content, the argument is a name," and it's worth respecting - argument names are matched exactly against the parsed request, so keep them lowercase, single words, no dashes, matching what users will type after --.

Install is the pack install (ComfyUI Manager, or clone into custom_nodes plus pip install -r requirements.txt), and there are no per-node dependencies or model downloads. The only workflow-level requirement is the pack's standing one: Auto Queue on, so the node is alive to receive the next request instead of running once and stopping.