Serving Text Output

ServingTextOutput is the unglamorous workhorse of the Serving Toolkit: it sends a plain text reply back to whoever made the request. No image, no fancy encoding - a string goes in, a message goes out to the Discord channel, the Telegram chat, the HTTP response, or the WebSocket. It's easy to skip when you're busy wiring up the image path, but it's the node that makes a bot actually feel like a bot.

Where it earns its keep: help commands. A !help branch that routes to a ServingTextOutput with a pre-filled text value gives users a list of commands and arguments without generating a single image. It's also the natural home for metadata - put a summary of the parameters used, or a message like "that prompt isn't allowed, here's why" after a failed check upstream. And it has a built-in fallback role: the image-input nodes (ServingInputImage and friends) use the serving config's text-send function to reply "This command requires an image" and interrupt the run when a command needed an attachment that never arrived. So even workflows that never wire up this node directly end up replying with text.

Inputs are minimal:

• text - the string to send. Multiline, so you can format help text or multi-line summaries.
• serving_config - the config from your entry point node.
• chained_execution (optional) - a SHOULD_EXECUTE signal from another output node, used to sequence multiple replies.

The output is a SHOULD_EXECUTE signal, which is the toolkit's chaining mechanism: it lets you send the text reply and then trigger a subsequent output node (like ServingOutput for the actual image) in a controlled order. Wire ServingOutput's chained_execution into this node's optional input and you get a status message followed by the image, reliably in that order.

Worth knowing: if you're on Discord or Telegram, text replies come back as normal message replies (mentioning the requester), not as images. On HTTP serving the text lands in the JSON response as a text field, and on WebSocket it comes back as a {"text": ..., "_requestId": ...} message. Same node, appropriate channel per platform.

Install is just the pack install - ComfyUI Manager, or clone into custom_nodes and pip install -r requirements.txt. No extra dependencies, no models. And like every node that waits on a request, it only works if Auto Queue is enabled on the workflow; if your !help handler fires once and never again, that toggle is the first thing to check.