Skip to main content
Glama

confirm_workspace

Ask a yes/no question on the ComfyUI canvas and wait for the user's decision before proceeding, preventing mistakes on slow or irreversible actions.

Instructions

Ask the person at the ComfyUI screen a yes/no question, and wait.

The same interruption as ask_workspace, for when the answer is a decision rather than a value - before something slow, or something with no undo.

Asked in the panel below the canvas by default, so the graph stays visible; modal=True puts it in a dialog over it. In the panel all three answers always have a button. In a dialog they do not:

confirmed has three values, and which are reachable depends on kind. True is agreement and null is dismissal - they closed the box, which says only that they did not engage with the question, and must not be read as either answer. A plain false needs a deny button, and ComfyUI draws one for dirtyClose and nothing else: every other kind offers Cancel and Confirm, so Cancel answers null and false never arrives. Ask for dirtyClose when telling "no" from "never mind" actually matters.

Args: question: what to ask. title: heading above it. Defaults to "Confirm". hint: smaller helper text under the question. deny_label: caption for the deny button. Only kind="dirtyClose" has one, so this is refused with any other kind rather than silently ignored. modal: ask in a dialog over the canvas instead of the panel below it. kind and deny_label describe ComfyUI's dialog and apply only then; the panel always offers Yes, No and Dismiss. kind: which of ComfyUI's confirmation dialogs to use - "default", "delete" and "overwrite" style the confirming button for a destructive act, "dirtyClose" is the three-way one, "reinstall" is ComfyUI's own. Only the wording and the buttons differ; nothing here acts on the answer. seconds: how long to wait, 1 to 600. client_id: which tab to ask; defaults to the most recently focused one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hintNo
kindNodefault
modalNo
titleNo
secondsNo
questionYes
client_idNo
deny_labelNo

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?

No annotations are provided, so the description carries full responsibility, and it delivers extensively: panel versus modal behavior, the three possible answer values, why null must not be read as either answer, which kinds can produce false, and that deny_label is refused with non-dirtyClose kinds. It also clarifies that kind only affects wording/buttons, not actions.

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?

The first sentence front-loads the core action, and the bolded key statement distills the trickiest behavioral nuance. Though the description is long, each sentence earns its place by covering a distinct behavioral or parameter detail necessary for correct invocation.

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?

Given 8 parameters with 0% schema coverage and no annotations, the description is remarkably complete: it covers every parameter, answer semantics, panel/dialog differences, kind-specific button availability, and timeout duration. Since an output schema exists, omitting explicit return-value prose is acceptable.

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%, but the Args section documents all eight parameters with meaningful behavior beyond the schema: title defaults to 'Confirm', seconds ranges from 1 to 600, deny_label only applies to dirtyClose, and modal changes whether kind and deny_label apply. This fully compensates for the schema's lack of descriptions.

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 specific verb-resource pair: 'Ask the person at the ComfyUI screen a yes/no question, and wait.' It then explicitly distinguishes itself from ask_workspace by contrasting a decision with a value, making its purpose unmistakable.

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 explicitly says this is the same interruption as ask_workspace but for decisions rather than values, and names concrete scenarios: 'before something slow, or something with no undo.' It also gives targeted guidance on when to use dirtyClose when distinguishing 'no' from 'never mind' matters.

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