Skip to main content
Glama

ask_workspace

Ask the person at the ComfyUI screen a question and wait for their answer. Use it when a step depends on human judgment or preference, optionally offering predefined choices.

Instructions

Ask the person at the ComfyUI screen a question, and wait for their answer.

This is the one tool whose answer comes from a human rather than from the graph. Reach for it when the next step turns on something only they know - which of two results they preferred, what the subject of a prompt should be, whether a value looks right - instead of guessing and building on the guess.

The question goes in a panel below the canvas, not over it. That matters for the question most worth asking - "look at this and tell me" - because a modal dialog hides the canvas and closes on a click beside it, so looking is what cancels it. In the panel the graph stays visible and usable, and they can pan around before answering. modal=True puts it back in a dialog for a question that should interrupt rather than wait to be noticed.

It costs them an interruption either way, so it is worth one question rather than three: only one can be waiting at a time, on either surface, and a second call while one is open is refused rather than queued.

choices turns it into a pick, which is the cheaper question to answer. One click instead of typing, and the answer comes back as one of the strings you offered rather than something to parse - with choice_index beside it, because two options can read alike once phrased and an index cannot. Up to six are drawn as buttons and more become a dropdown. Choices need the panel: a dialog has no way to offer them, so modal=True with choices is refused.

allow_other adds a free-text box beside the buttons, for when the list may not cover it; the answer then comes back with choice_index: -1. Leave it off when the options really are exhaustive - it is one more thing on screen.

Three outcomes, and they mean different things. answer is what they typed or picked. dismissed means they closed the box without answering - easy to do by accident, since clicking beside it counts, so it is not a "no" and not permission to carry on regardless. timed_out means the wait ran out with the question still on screen; they may yet answer it, and until they do, another question cannot be asked.

Args: question: what to ask. Shown as the body of the dialog. title: heading above it. Defaults to "Question". default: text the input starts with, for when there is an obvious answer. placeholder: grey hint inside an empty input, or in the allow_other box. choices: options to offer instead of a text box. Each is a button (or an entry in a dropdown past six of them) and answering picks one. allow_other: add a free-text box beside the choices, answering with choice_index: -1. Ignored when there are no choices. modal: ask in a dialog over the canvas instead of the panel below it. Harder to miss, but it hides the graph and a stray click dismisses it, so it suits a question whose answer needs nothing on screen. seconds: how long to wait, 1 to 600. Keep it well under the per-call timeout your MCP client enforces, or the client gives up first. client_id: which tab to ask; defaults to the most recently focused one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modalNo
titleNo
choicesNo
defaultNo
secondsNo
questionYes
client_idNo
allow_otherNo
placeholderNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Install Server

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full disclosure burden and does so thoroughly. It explains panel versus modal behavior, refusal conditions (modal+choices), the meaning of dismissed vs timed_out vs answer, and the consequence of dismissal ('not permission to carry on regardless'). This is far beyond what annotations would typically provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although long, the description earns its length by covering interactive edge cases that are invisible in the schema. It is front-loaded with the core purpose and uses bold lead-ins and short paragraphs to keep each behavioral section scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a human-interaction tool with no annotations, this description is remarkably complete. It covers the three answer outcomes, timeout considerations vs client timeout, multi-client targeting, choices rendering, and all invalid combinations, leaving no critical ambiguity for invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully explain parameters, and it does. Every one of the 9 parameters has an individual entry with meaning, default behavior, and often edge-case constraints, such as allow_other producing choice_index: -1 and modal being refused with choices.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb and resource: 'Ask the person at the ComfyUI screen a question, and wait for their answer.' It explicitly distinguishes itself from graph-derived tools by stating it is 'the one tool whose answer comes from a human rather than from the graph,' which separates it from all sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance: 'Reach for it when the next step turns on something only they know' with concrete examples, and contrasts with guessing. It also documents conditions to avoid misuse, such as not making multiple simultaneous questions because 'a second call while one is open is refused rather than queued.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pytraveler/local-comfyui-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server