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

With no annotations provided, the description carries the full burden. It discloses atomicity (one edit, one Ctrl+Z), all-or-nothing validation ('Nothing is added unless every value and link validates'), link type checking with litegraph's silent failure, and defaults for pos, title, and client_id. This goes well beyond a simple 'adds a node' statement.

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

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

The description is well-structured with a purpose statement, rationale, validation note, and parameter breakdown. It is slightly verbose with the explanation of the one-call undo advantage, but that content is relevant and not wasteful. Overall, it is appropriately sized for the tool's complexity.

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

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

Given the tool's complexity (7 parameters, connect syntax, error behavior), the description is complete. It covers all parameters, defaults, validation, and failure modes. The output schema exists, so not detailing return values is acceptable. The context of the workflow editor and user experience (e.g., default pos to current view) is also addressed.

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

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

The Args section explains every parameter in detail, providing examples, defaults, and syntax. For instance, 'connect' is illustrated with `{"from": "this.IMAGE", "to": "9.images"}` and the meaning of 'scope' is defined. Since schema description coverage is 0%, this description fully compensates and adds significant value.

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

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

The description begins with a clear, specific statement: 'Add a node to the workflow open in the browser, wired up and configured.' This distinguishes the tool from siblings like set_workspace_links or set_workspace_values, as it covers the full addition with wiring and configuration in one operation.

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

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

The description explicitly advises doing the addition in one call to get a single Ctrl+Z undo and avoid stray nodes from partial failures. It contrasts this with splitting the work into three calls, thus giving clear context for when to use this tool over a combination of separate operations. It does not mention alternative tool names explicitly, but the guidance is clear enough.

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

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

With no annotations, the description fully discloses behavior: it moves nodes along one axis only, accounts for node draw sizes including collapsed nodes, explains the effect of apply=false, and warns about contradictory edge/distribute combinations. This goes far beyond basic operation.

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

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

The description is front-loaded with the main purpose, then uses concise paragraphs for distinction, edge cases, and parameter details. Every sentence earns its place, and the structure flows logically from use-case to parameter explanations.

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

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

Given the output schema exists, return values need no explanation. The description covers all parameters, usage scenarios, edge cases, and even interactions between parameters. It is complete for a complex tool with 7 parameters.

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

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

Despite 0% schema description coverage, the Args section documents all seven parameters with meaningful details (e.g., 'centre forms use the middle of the whole selection', 'spacing: an exact gap for distribute'). This compensates completely 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.

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

The description starts with a specific verb and resource: 'Line nodes up on a common edge, space them evenly, or both.' It explicitly contrasts with sibling tool arrange_workspace, stating 'Unlike arrange_workspace this never reads a link...' This clearly distinguishes the tool's purpose and scope.

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

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

The description provides explicit when-to-use guidance: 'Reach for this when the graph is already laid out the way the author wants and only looks untidy.' It also names the alternative tool (arrange_workspace) and explains the difference, making the choice context clear.

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

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

With no annotations, the description carries the full behavioral burden and meets it: it warns that arranged groups otherwise scatter into overlapping sheets, discloses that the result keeps its existing top-left corner, and explains that apply=False computes without touching the canvas. It also calls out the blunt behavior that every node it is given will be moved.

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

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

The description is longer than average but earns its length: each paragraph covers one behavioral facet—layout rule, group handling, scope, and parameters—and the most important outcome is front-loaded in the first sentence. The prose examples clarify rather than pad.

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

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

Given the tool's complexity, the absence of annotations, and the presence of an output schema, the description is complete: it explains the algorithm, group block behavior, node-scoped mode, coordinate meanings, apply vs report, scope constraints, and tab targeting. No critical operational question is left unanswered.

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

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

Schema coverage is 0%, so the description must compensate, and it does: an Args section defines all seven parameters with meaningful semantics, e.g. origin defaults to the arranged content's top-left, client_id means the recently focused tab, and scope explains why 'all' is not supported. This goes far beyond bare parameter names.

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

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

States a specific verb and resource: 'Lay the workflow out left to right, in the order the data flows through it.' The description explains the layout rule and the preserved corner, making it clear this is a data-flow-aware arrangement rather than a generic alignment tool.

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

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

Gives explicit when-to-use and when-not-to-use guidance: 'only' arranges just those nodes and leaves the rest alone, and scope is explicitly limited: 'Not "all"' with a pointer to navigate_workspace for subgraphs. It also directs users to set_workspace_layout when apply is False, naming the alternative path.

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

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.

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.

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.

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.

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.

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.

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses a key side effect: 'What has arrived stays in the .part file' and that subsequent download_model calls continue rather than restart. It also cautions about counter-productive use on slow transfers. However, it doesn't mention edge cases like idempotency or error behavior when the download is already finished, which would round out transparency.

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

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

The description is efficiently structured: a clear one-sentence purpose, a brief behavioral note, and a labeled Args section. Every sentence adds unique value, and the format is front-loaded with the essential verb and resource.

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

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

For a tool with a single optional parameter and an output schema, the description covers all necessary aspects: purpose, usage guidance, parameter semantics, and behavioral transparency. It is fully complete for the tool's simplicity and leaves no critical gaps for an agent to invoke it correctly.

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

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

The schema only provides job_id with a default of '', but the description adds complete semantics: it specifies the format '<folder>/<filename>', the shorthand of just the filename, and that empty means 'the most recent download.' This fully compensates for the 0% schema description coverage.

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

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

The description clearly states 'Stop a download that is still running,' which is a specific verb+resource action. It distinguishes itself from sibling tools like download_model (starts downloads) and get_download_progress (queries progress), and from interrupt which likely targets workflows rather than file downloads.

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

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

The description gives explicit when-to-use (stop a running download) and when-not-to-use guidance: 'For a transfer that is merely slow this is counter-productive.' It also explains the alternative of calling download_model again to resume, effectively providing a clear usage context and exclusion.

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

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

With no annotations provided, the description fully discloses the irreversible nature, the unsaved changes risk, the force behavior, tab matching ambiguity, the refusal of the last remaining tab, and the canvas neighborhood transition. It also states that nothing is written to disk and nothing can be undone, providing essential behavioral context beyond annotations.

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

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

The description is organized into a purpose paragraph, a behavioral caution paragraph, a canvas behavior note, and a parameter list. Every sentence adds useful information, and the structure makes it easy to scan. While detailed, each part contributes to safe selection and effective invocation.

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

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

The tool has an output schema and no required parameters, and the description still covers why, when, how, and what consequences apply. It explains ambiguous cases, refused edge cases, and save-related interaction with other tools. The description is fully sufficient for an agent to select and call this tool correctly.

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

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

Even though the input schema has no descriptions (coverage 0%), the description explains all three parameters clearly: tab's accepted forms (index/path/filename/empty), force's meaning and risk, and client_id's role as the browser tab identifier. This fully compensates for the schema gap.

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

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

The description opens with a specific verb and resource: "Close one of the workflow tabs open in the ComfyUI window." It clearly distinguishes itself from related tools like switch_workspace_tab, save_workspace, and the various workspace manipulation tools by focusing on tab lifecycle cleanup.

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

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

The description explicitly frames when to use this tool: as the counterpart to switch_workspace_tab, and as the way to tidy up after loads that each open a tab. It contrasts behavior with save_workspace and explains that only ComfyUI's own Save clears the dirty flag, giving clear functional context and exclusions.

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

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

With no annotations, the description carries the burden of disclosing behavior. It does add useful context: the 'wait' argument blocks until the HTTP API responds, with a timeout. However, it omits other important behaviors like what happens if the instance is already running, error handling, or whether it launches asynchronously when wait=false.

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

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

The description is very short and front-loaded with the core purpose. The 'Args' section is minimal but earns its place by explaining the single parameter. There is no fluff, though it could arguably include one or two more essential details without becoming wordy.

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

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

For a tool with a single optional parameter and an output schema, the description covers the main action and wait behavior. However, it leaves gaps such as behavior when already running, the meaning of COMFYUI_STARTUP_TIMEOUT, and any failure modes. This is average completeness for a launch tool of low complexity.

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

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

The schema only provides a boolean named 'wait' with a default, but the description explains its meaning: block until the HTTP API answers, subject to COMFYUI_STARTUP_TIMEOUT. This adds meaningful semantic context that the schema lacks, especially with 0% schema description coverage.

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

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

The description uses the specific verb 'Launch' and identifies the resource as 'the portable ComfyUI instance', clearly distinguishing it from sibling tools like comfy_stop and restart_comfy. While it doesn't explicitly say 'start the server', 'Launch' is unambiguous in this context.

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

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

No guidance is given on when to use comfy_start instead of alternatives such as restart_comfy or comfy_status. The 'wait' argument implies a use case (blocking until ready) but there is no explicit when-to-use or when-not-to-use instruction.

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

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

No annotations are provided, so the description is the sole source. It clearly communicates a read-only status check by stating 'Check... report', but does not disclose error behavior or potential side effects, which are relevant for a diagnostic tool.

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

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

A single concise sentence that front-loads the verb and lists specific report items. No wasted words, making it easy to parse.

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

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

Given the tool's simplicity (no params, output schema present), the description adequately covers the check functionality and report scope. No additional context is required.

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

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

The tool has zero parameters, so the schema fully covers parameter semantics. The description does not need to add parameter details, and therefore the baseline score of 4 applies.

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

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

The description uses a specific verb ('Check') and resource ('ComfyUI') and specifies the exact outputs (GPU/VRAM and queue state), clearly distinguishing it from start/stop sibling tools.

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

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

The description implies usage for health checks, but does not explicitly compare to alternatives like get_queue or get_comfy_log, and does not state when not to use it. Guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full responsibility of explaining that this is a potentially destructive operation. It discloses that it stops the process 'and everything under it,' that it deliberately avoids user-launched ComfyUIs, and that it can target even orphaned instances recorded on disk from before a restart. This is all substantive behavioral context beyond basic 'stops the process.'

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

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

The description is compact, front-loaded, and contains no filler. Each sentence earns its place: the core action, the ownership boundary, and a necessary edge-case about orphaned instancestarted before restart.

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

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

For a zero-parameter mutating tool with no annotations, this description covers its main purpose, scope, limitations, and edge cases. The output schema is present, so there is no hidden expectation to explain return values, and nothing important for an agent to make the right call is missing.

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

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

The tool has zero parameters, so the baseline is 4. The description adds relevant operational context about what will be stopped but does not need to document argument semantics because there are none.

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

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

The description begins with a specific verb-resource combination: 'Stop the ComfyUI process that this server started, and everything under it.' It clearly distinguishes the target from related tools such as comfy_start, restart_comfy, and interrupt by focusing on stopping the whole managed process tree.

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

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

The description gives explicit context for when this tool applies: it can only stop instances owned by this server, and the ownership test is explained sharply ('not whether something is answering the port'). It says when not to use it, but does not name alternative tools such as comfy_start or interrupt, so it stops short of full alternative routing.

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

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.

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.

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.

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.

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.

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.

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the difference between summary and raw output, warns about the potentially huge size of full option lists (199k characters), and implies that summaries may be truncated. It could also explicitly state the tool is read-only, though 'look up' strongly implies this.

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

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

The description is concise and front-loaded, starting with a clear purpose statement and then logically flowing into usage context and parameter explanations. Every sentence adds value, with no wasted words or repetition.

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

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

The description is complete for a lookup tool. It explains what the tool returns, how to use it with related tools, and the trade-offs of the 'full' parameter. An output schema exists, so detailed return values are not needed in the description. The tool's simplicity and good documentation make this fully adequate.

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

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

The schema provides only basic types and titles, and the context signals show 0% schema description coverage, so the description must fully compensate. It does: class_type is explained as 'the node's class name, e.g., KSampler,' and full is described as returning the raw /object_info entry with important caveats about size and completeness.

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

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

The description clearly states the tool's purpose: 'Look up one node type: its inputs, their valid values, and what it outputs.' It distinguishes itself from related tools by referencing find_node_types for obtaining class_type and by explaining how describe_node fits into the workflow with add_workspace_node and run_workflow.

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

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

The description explicitly tells when to use the tool: 'Use before wiring a node in with add_workspace_node, or to check allowed combo values... before passing them to run_workflow.' It also clarifies the relationship to find_node_types and advises when to use the 'full' parameter, providing clear context and exclusions.

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

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

With no annotations, the description carries the transparency burden. It discloses automatic resolution through primitives/switches, dynamic schema enrichment when ComfyUI is running, and the fact that schemas are cached (prompting refresh_schemas). It does not explicitly state the operation is read-only, but 'Report' implies no mutation; this is a minor omission.

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

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

The description is well-structured: a purpose sentence, a paragraph on parameter resolution behavior, a paragraph on dynamic schema details, and an Args list. Every sentence adds value with no fluff or redundancy, achieving strong conciseness for a tool with moderate complexity.

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

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

The description covers inputs, key behaviors (resolution, caching, dynamic types), and mentions outputs. Since an output schema exists, return-value details need not be in the description. It lacks explicit guidance on when to use versus alternatives (covered in usage_guidelines) and does not mention error cases, but overall it is sufficiently complete for an agent to invoke correctly.

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

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

Schema description coverage is 0%, so the description must compensate. The Args section explains both parameters: 'name' is the workflow file name without .json extension, and 'refresh_schemas' re-reads node schemas and should be used after installing models/custom nodes because schemas are cached. This adds meaningful semantics beyond the raw schema.

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

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

The description opens with 'Report the parameters a workflow accepts, plus its outputs and model files,' which specifies the verb and resource. It clearly distinguishes from siblings like list_workflows (listing) and describe_node (node-specific), while sharing the 'workflow' domain.

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

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

The description implies usage when you need to inspect a workflow's parameters/outputs, but it does not explicitly state when to use this over describe_node, get_workflow_guide, or list_workflows. No exclusions or alternative tool mentions are provided.

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

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

No annotations exist, so the description carries full burden. It discloses that it reads the live graph, checks against node schemas, reports muted/bypassed nodes, includes caching behavior for schemas, and explicitly states that it does not guarantee the run will succeed. This is thorough behavioral disclosure.

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

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

The description is well-structured and front-loaded with the main purpose. It is somewhat longer than the minimal needed, but each sentence adds meaningful context (e.g., node schema checks, fix tools, limitations, parameter details). No fluff or repetition.

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

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

Given the tool's complexity, the description covers functionality, parameter semantics, relationship to fix tools, default behavior, and limitations. With an output schema present, there is no need to describe return values, making the description complete for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 0%, but the description explains all three parameters: scope ('all', 'root', or 'active' with reference to get_workspace_graph), refresh_schemas (re-fetch /object_info, caching lifecycle), and client_id (which tab to inspect, default behavior). This fully compensates for the missing schema descriptions.

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

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

The description opens with 'Report what is wrong with the workflow open in the browser, worst first,' a specific verb+resource statement. It clearly distinguishes itself from sibling tools by mentioning that 'the other workspace tools are what applies it' and listing them.

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

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

Provides explicit alternatives and guidance: names set_workspace_links, set_workspace_values, etc. as the tools that apply fixes, explains why default scope='all' is set, and states that a clean report is not a promise of run success. This gives clear when-to-use and when-not-to-rely guidance.

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

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

With no annotations, the description uniquely carries the full burden of behavioral disclosure. It covers critical quirks: ComfyUI decides the actual directory honoring extra_model_paths.yaml, interrupted transfers resume via .part files, wait vs. asynchronous behavior, and that the reply names the chosen directory. No annotation contradiction exists.

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

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

The description is long but every sentence adds value. It is front-loaded with a crisp purpose, then logically flows into usage context, behavioral caveats, and a clear Args list. The formatting with bolded keys and defaults makes it scannable despite its length.

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

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

The tool is complex (7 params, ComfyUI integration, resumable downloads), and the description covers all aspects: purpose, prerequisites (checking list_models), alternatives, error-prone behaviors, and parameter usage. An output schema exists, so not detailing return values is appropriate.

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

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

Schema has 0% coverage, so the description must and does explain every parameter in depth. It clarifies url's provenance, folder examples, filename defaults and subdirectory support, directory selection logic, wait's async behavior, overwrite semantics, and dry_run's purposeful size/checksum preview.

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

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

The description opens with a specific verb+resource: 'Download a model file into the folder ComfyUI will actually load it from.' It clearly distinguishes from siblings like list_models and get_download_progress by focusing on the actual download action and its integration with ComfyUI's model folders.

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

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

Provides explicit guidance: 'check what is already there with list_models(folder) first', recommends dry_run ('Worth doing first'), and directs large downloads to get_download_progress ('prefer that for anything large'). It also explains when the tool is intended ('for the models a workflow declares on its own loaders').

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

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

With no annotations, the description carries the full burden and excels. It discloses AND semantics, wildcard behavior ('Wildcard ('*') slots match anything'), default exclusions (include_deprecated off), inclusion of experimental nodes, the refresh requirement after installing nodes, and limit behavior ('What matched beyond it is still counted'). It also notes that each result carries the node's slots, so additional calls may be unnecessary. This is deep, actionable transparency.

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

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

The description is front-loaded with the core purpose, followed by a short paragraph on filter semantics, then a structured Args list. Every sentence earns its place: examples, exclusions, and parameter details are dense but not redundant. Despite covering 9 params, it remains appropriately sized and well organized.

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

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

Given the tool's complexity (9 optional parameters, no annotations) and the presence of an output schema, the description is complete. It explains all parameters, usage context, alternatives, and behavioral nuances. There are no obvious gaps; an agent will know exactly when and how to invoke this tool.

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

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 compensate, and it does. Every one of the 9 parameters is explained with examples ('search: case-insensitive substring... why 'latent to image' finds VAEDecode'), type semantics ('input_type' vs 'output_type'), wildcard ranking, and default behaviors. This adds substantial meaning beyond the bare parameter names and types in the schema.

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

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

The description opens with a specific verb and resource: 'Find a node type to add to a workflow, by name or by what it connects to.' It clearly distinguishes this from sibling tools like describe_node by stating when to use describe_node instead (for a widget's allowed values). The purpose is unmistakable and differentiated.

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

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

Explicit guidance is provided: 'Filters are ANDed and all are optional; with none of them this lists what is installed.' It also names the alternative: 'reach for describe_node when you need a widget's allowed values.' The 'type filters answer the question a graph editor actually asks' gives concrete use cases, making when/how to use this tool clear.

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

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

With no annotations provided, the description accurately discloses the main behavior: asking ComfyUI to unload models and free VRAM. However, it omits potential side effects like reloading delays or impact on running workflows, though the action itself is clearly and transparently described.

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

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

The description is a single concise sentence, efficiently conveying the tool's purpose without any fluff. Every word earns its place, and the structure is appropriately front-loaded.

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

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

The tool is simple with one optional parameter and an output schema, so the description covers the basic function adequately. However, it lacks context about when to use it, potential side effects, or prerequisites like ComfyUI being running, making it not fully complete for an AI agent.

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

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

The input schema has one parameter (unload_models) with 0% description coverage, and the tool description does not mention this parameter at all. The description adds no meaning beyond the parameter's name and default value, failing to compensate for the schema's lack of detail.

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

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

The description clearly states the tool's purpose with a specific verb and resource: 'unload models and free VRAM.' It distinguishes this from sibling tools like comfy_stop (which stops ComfyUI) and restart_comfy, making the tool's unique role apparent.

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

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

The description implies usage when the user wants to free VRAM by unloading models, but it does not explicitly state when to use this tool versus alternatives or mention any prerequisites. There is no guidance on when not to use it, such as during active workflows.

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

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

No annotations are provided, so the description carries the full burden. It clearly states this reads the Python-side console, not the browser, and explains what kind of output it returns (import errors, tracebacks). It also discloses filtering behavior (level drops untagged output, search/regex). This is strong behavioral disclosure, though it stops short of describing the exact output format or side effects.

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

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

The description is moderately sized but every sentence adds value. The opening paragraph establishes the tool's unique value, and the Args section is terse and unambiguous. No filler or redundancy.

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

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

Given the tool's niche role, the description covers the core use case, differentiates from other tools, and explains all parameters. An output schema is present, so return structure details are not required. The context of sibling tools is addressed through the Python-vs-browser distinction.

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

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

Schema descriptions are absent (0% coverage), but the description thoroughly explains all four parameters: lines, level, search, regex. It clarifies that level drops untagged output, and regex modifies search. 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.

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

The description opens with 'Read ComfyUI's console - the Python side', giving a specific verb and resource. It clarifies this is the terminal, not the browser, differentiating it from the sibling get_console_log. The contrast with /object_info also helps distinguish its niche.

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

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

The description explains that import failures and tracebacks land here, and that nothing else in the server can see this data. This implies use when a node fails to load or when debugging dependency issues. It contrasts with /object_info but does not explicitly name the sibling get_console_log as the alternative, though the Python-vs-browser distinction makes the intended usage clear.

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

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

With no annotations, the description carries the full burden and does well: it reveals the ephemeral nature of logs ('only sees what was logged since that tab loaded'), the need for a connected tab, and that extension import errors are only console.error'd, making this the sole record. It could go further by describing the output structure, but an output schema exists, so the return format is covered elsewhere. The description adds meaningful behavioral context beyond the schema.

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

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

The description is well-structured and front-loaded with the core purpose, followed by context, limitations, and an Args list. While it contains extra explanatory prose about node architecture, every sentence adds value by distinguishing this tool from alternatives and explaining why it exists. It is slightly longer than strictly necessary but not wasteful, earning a 4 rather than a 5.

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

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

Given the tool's moderate complexity (5 parameters, no annotations, output schema present), the description is remarkably complete. It covers purpose, usage scenario, prerequisite, data scoping, and all parameter semantics. The only missing piece would be concrete examples, but they are not essential for a read-only log retrieval tool. The description fully equips an agent to select and invoke this tool correctly.

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

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

The input schema only provides titles and defaults, with 0% description coverage. The description compensates fully by explaining each parameter in plain language: lines (how many recent matching entries, 0 for all), level (severity filter with allowed values), search (case-insensitive text filter), regex (treat search as regular expression), and client_id (which tab). This adds clear meaning beyond the schema titles.

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

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

The description opens with a specific verb and resource: 'Read the browser console - the frontend half.' It explicitly distinguishes itself from sibling get_comfy_log by explaining that it answers a different question about frontend extension failures. The purpose is unmistakable and well-scoped.

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

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

The description clearly contrasts with get_comfy_log, stating 'it answers a different question' and details the scenario where a JavaScript half fails while the Python half succeeds, making this the only tool that can see such failures. It also notes a prerequisite: 'Needs a connected tab' and warns that only logs since tab load are visible. This gives explicit when-to-use and behavioral context.

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

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

With no annotations, the description carries the full burden. It discloses that stalled transfers auto-resume and should not be cancelled, and explains how to interpret silent_for_s. It also implies read-only nature via 'Report', but does not explicitly confirm non-mutation or error handling.

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

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

The description is well-structured with a concise main purpose, a useful interpretive note, and a clear argument specification. Every sentence adds value; no fluff or repetition.

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

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

For a single-parameter read-only tool with an output schema, the description covers all needed context: parameter format, interpretation of results, and actionable guidance. It is complete enough for an agent to use correctly.

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

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

The description fully documents the only parameter job_id, providing three acceptable forms: folder/filename, filename only, or empty for most recent. This goes far beyond the schema, which only shows a default value.

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

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

Begins with a specific verb and resource: 'Report how far a download has got' and lists concrete outputs (bytes, percent, speed, ETA). This clearly distinguishes it from related tools like download_model and cancel_download.

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

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

Provides clear operational guidance: explains that silent_for_s indicates stall vs. slow link, and advises waiting for silence exceeding COMFYUI_DOWNLOAD_TIMEOUT before acting. However, it does not explicitly mention alternative tools or when not to use this tool.

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

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

With no annotations provided, the description carries the full burden. It discloses how to interpret the output: 'silent_for_s is the telling number: it stays small while the job advances, and only a large and growing one means something is actually wrong.' It also explains expected behaviors like model loading producing no steps for a minute, showing up as 'working'. This is exemplary transparency beyond a simple operation description.

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

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

The description is well-structured, starting with a succinct summary, followed by essential context and an args explanation. Every sentence adds value—no fluff. While it is longer than minimal, the additional details (e.g., 'silent_for_s', cost of interrupting) directly support correct usage, making it appropriately sized for the tool's complexity.

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

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

Given the tool has only one optional parameter and no annotations, the description fully covers the parameter semantics, output interpretation, and behavioral context. It explains what is reported (step, percent, elapsed time, ETA), how to interpret silent_for_s, and why waiting is preferable to interrupting. No critical information is missing.

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

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

The input schema only defines prompt_id as a string with a default. The description compensates fully with an Args section: 'prompt_id: which run to report on. Defaults to the most recent one.' This clarifies the exact meaning and default behavior, going significantly beyond the schema. Since schema description coverage is 0%, this compensation is essential and well-executed.

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

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

The description clearly states the tool's purpose: 'Report how far a run has got: step, percent, elapsed time and an ETA.' It uses a specific verb ('report') and resource ('a run'), and distinguishes itself from sibling tools like get_download_progress and get_result by focusing on run progress.

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

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

The description gives strong guidance on when to use the tool: 'A generation takes minutes... check here instead of guessing.' It also advises against interrupting and re-running: 'Interrupting and re-running costs more than waiting.' While it doesn't explicitly name alternative tools, it provides clear contextual direction.

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

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

With no annotations, the description carries the full burden. It discloses a useful behavioral nuance: running items carry progress only when started by this server, and it notes that get_progress gives the same detail for one run. However, it doesn't mention side effects, safety, or potential absences of progress information beyond this caveat. This is adequate but not rich.

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

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

Two sentences, front-loaded with the main purpose, and every sentence adds value. The second sentence provides a caveat and a sibling reference without wasted words.

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

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

The tool is simple (no params) and has an output schema that presumably describes the return format. The description covers what the tool shows, the progress nuance, and a pointer to get_progress, making it complete for this context.

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

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

The tool has zero parameters and 100% schema coverage, so no parameter guidance is needed. The description correctly omits parameter details, and the baseline for 0 params is 4.

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

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

The description opens with a specific verb ('Show') and resource ('ComfyUI currently running and queued'), clearly stating what the tool does. It also distinguishes itself from the sibling tool get_progress by noting that get_progress is for a single run, making the purpose unambiguous.

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

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

The description implies when to use this tool (for an overview of the queue) and explicitly mentions get_progress as an alternative for one-run detail. It provides clear context but doesn't explicitly state exclusions or other alternatives, so a 4 is appropriate.

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

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

With no annotations, the description bears full responsibility for disclosing behavior. It only states that outputs are fetched without explaining what happens if the prompt ID is invalid, whether the operation blocks until outputs are ready, or whether partial outputs are possible. The minimal detail leaves key behavioral traits unspecified.

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

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

The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple tool, though it omits usage details that would not significantly lengthen it. The structure is clean and readable.

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

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

Despite an output schema existing, the description does not cover when to use the tool, prerequisite conditions, or error behavior. The single sentence is under-specified for a tool that likely depends on a prior submission, and it does not reference sibling tools or lifecycle context, leaving notable gaps.

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

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

The schema has zero description coverage for prompt_id, so the description must compensate. It implies that prompt_id refers to the ID of a previously submitted prompt, which is useful context. However, it does not explain how to obtain the ID, its format, or any constraints, leaving some ambiguity.

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

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

The description states a clear action ('Fetch the outputs') and a resource ('previously submitted prompt'), which distinguishes it from tools like get_progress or get_queue. It is not as specific as naming an alternative or the exact prompt format, but it is unambiguous about the tool's core function.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be called after submitting a prompt, nor does it point to get_progress for status checking. The lack of any usage context or exclusions leaves the agent to infer the appropriate timing.

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

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

No annotations are provided, so the description carries the full burden. It discloses that this is a read operation ('Read'), explains the purpose of the file, and gives an example of the kind of content it contains. It does not explicitly mention error handling or return format, but the output schema is present, and the description adds useful context about the file's naming convention and when guides exist.

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

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

Although the description is longer than a simple sentence, every part earns its place: the opening sentence states the purpose, the middle explains the reasoning with a concrete example, the third gives usage guidance, and the final documents the parameter. It is well-structured and front-loaded, with no redundancy.

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

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

For a simple one-parameter tool, the description is comprehensive. It explains why the tool exists, when to use it, how to identify applicable workflows, and the exact format of the parameter. The output schema presumably covers return values, so the description needn't elaborate further. This is complete for an agent to select and invoke the tool correctly.

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

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

The schema has one parameter with no description, but the description provides the necessary clarification: 'workflow file name, without the .json extension.' This is critical information that the schema lacks, fully compensating for the 0% schema description coverage. The parameter is fully explained.

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

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

The description clearly states the tool reads an instruction file that ships with a workflow, using the specific verb 'Read' and specifying the resource. It also distinguishes itself from sibling tools like describe_workflow by explaining that it retrieves the guide file, not the workflow definition. The example with Ideogram 4 adds concrete context.

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

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

The description explicitly says to read and follow the guide before calling run_workflow, which is a clear when-to-use directive. It also explains that workflows with a guide are flagged as `guide` by list_workflows and describe_workflow, providing a way to identify when this tool is applicable versus alternatives.

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

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

With no annotations provided, the description fully carries the burden and excels. It discloses unsaved edits inclusion, the 'reduced' step-down behavior for large graphs, the 'api' format being frontend-only, scope semantics with path ids, and the ceiling behavior of detail. This goes well beyond what annotations could provide.

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

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

The description is long but every sentence earns its place. It front-loads the core purpose and then systematically explains parameters and edge cases. The 'Args' section is well-structured and avoids fluff.

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

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

Given the tool's complexity (5 params, 0% schema coverage, no annotations), the description is remarkably complete. It explains return formats, reduction semantics, subset walking with 'feeds', and the unique api format value. The presence of an output schema reduces the need to describe return structures, and the description covers everything else needed for correct invocation.

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

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

Schema description coverage is 0%, yet the description explains all five parameters in depth: format with three distinct return types, scope with examples and nested-node path ids, detail with three levels and ceiling behavior, only with the special 'selected' value, and client_id with default and listing source. This fully compensates for the missing schema descriptions.

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

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

The description opens with a specific verb and resource: 'Read the workflow currently open in the browser, unsaved edits included.' It clearly differentiates itself from siblings by stating 'use describe_workflow for the files in the workflows directory' and emphasizes its unique ability to report what the user is looking at.

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

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

Explicit usage guidance is provided: when to use this tool vs describe_workflow, how to interpret 'selected' as pointing during user requests, when to use 'only' for reduced large graphs, and how set_workspace_selection points back the other way. This covers both when and when-not to use it.

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

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

With no annotations provided, the description must carry the full behavioral disclosure burden. It does so by explaining the destructive consequence ('steps already computed are lost') and the side effect ('models get reloaded'), which is exactly the kind of context an agent needs before calling an interrupt operation.

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

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

The description is two sentences long, front-loaded with the primary action, and every sentence earns its place by adding either purpose or usage warnings. There is no wasted or redundant text.

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

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

Given that the tool takes no parameters and an output schema exists, the description fully covers what an agent needs: what the tool does, when not to use it, and what to do instead. It is complete and self-contained for this simple operation.

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

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

The tool has zero parameters and the input schema is empty, so there is nothing to clarify. The baseline of 4 is appropriate because no parameter information is needed beyond what the schema already states.

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

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

The description uses a specific verb ('Interrupt') and clearly identifies the resource ('the job ComfyUI is currently executing'). This distinguishes it from sibling tools like cancel_download or get_progress, making its purpose unambiguous.

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

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

The description provides explicit when-not-to-use guidance: it is counter-productive for merely slow runs. It also directly advises checking get_progress first, giving a clear alternative action and helping the agent decide when this tool is appropriate.

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

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

With no annotations, the description carries the full burden. It reveals that the tool 'Asks ComfyUI itself,' meaning it depends on a running ComfyUI instance and reflects live configuration. It also explains the risk of disk scans due to mapped model folders, giving useful context beyond a simple list operation. However, it does not mention error behavior or authentication assumptions, which keeps it from a 5.

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

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

The description is efficiently structured: a one-sentence summary, a short explanatory paragraph about why it differs from disk scans, and a clean Args list. Every sentence contributes information without redundancy, making it easy to scan.

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

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

Given the output schema exists and this is a read-only listing operation, the description covers the core requirements: purpose, behavior, rationale, and parameter usage. It lacks explicit mention of failure modes (e.g., ComfyUI not running), but that is implied by 'Asks ComfyUI itself' and does not undermine effective use. The description is robust and complete enough for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must explain all three parameters. It does so thoroughly: folder lists example values and default behavior (empty means folder names), search is specified as case-insensitive substring filter, and limit is defined as maximum files returned. This fully compensates for the bare schema and adds meaningful guidance.

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

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

The description immediately states the exact function: 'List the models ComfyUI can actually load.' It goes further by distinguishing this from a plain disk scan, clarifying that it queries ComfyUI itself to honor extra_model_paths.yaml. This sets it apart from any filesystem-based listing and clearly identifies the resource and verb.

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

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

The description provides clear context: use this tool to get the list of models ComfyUI actually accepts, especially when extra_model_paths.yaml is in play. It explicitly advises against a plain disk scan, offering a concrete 'when not to use' scenario. It doesn't name alternative sibling tools like download_model, but the guidance is strong enough to avoid misuse.

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

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

With no annotations, the description carries the full burden. The word 'List' indicates a read-only operation, but the description does not disclose details such as whether subdirectories are recursively searched, file extensions filtered, or what happens if the directory is missing. This is acceptable for a simple list but lacks richer behavioral context.

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

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

The description is a single sentence that efficiently conveys the essential action and target. Every word earns its place, and there is no redundant information.

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

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

Given the simplicity of a list operation and the presence of an output schema, the description is sufficient for understanding the tool's behavior. It could optionally mention whether the list is sorted or includes file schemas, but the core purpose is clear and complete.

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

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

The tool has zero parameters, so there is no parameter semantic burden. The schema is empty and the description does not need to explain any inputs, aligning with the baseline for parameterless tools.

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

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

The description clearly states the verb 'List' and the resource 'API-format workflow files' with the location 'workflows directory'. It implicitly distinguishes from siblings like describe_workflow or run_workflow by focusing on listing files, but it does not explicitly contrast with any sibling.

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

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

The usage context is implied: this tool lists available workflow files, presumably for discovery before running or describing them. However, there is no explicit guidance on when to use this tool versus alternatives like list_models or describe_workflow, and no exclusions are stated.

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

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

The description is exceptionally transparent about non-obvious behavior: it opens a tab rather than replacing the current one, explains when tab reuse occurs, warns that the operation is not undoable, and documents the backup mechanism. Since no annotations are provided, the description fully bears the burden of behavioral disclosure and does so thoroughly.

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

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

While the description is lengthy, the length is justified by the complexity of the behavior. It starts with a summary, then covers important edge cases in focused paragraphs, and ends with a clear Args section. Each sentence adds value, and the structure makes the information easy to parse.

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

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

The description covers all critical context: file format differences, tab behavior, naming conflicts, undo behavior, backup fallback, and parameter semantics. It also references what the reply contains, such as tab information and backup file naming, which aligns with the existing output schema. This is a comprehensive description for a tool with this level of behavioral nuance.

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

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

The input schema provides zero description coverage (0%), but the description's Args section compensates fully by explaining what each parameter means, including name resolution order, backup behavior and default, force semantics, and client_id targeting. This goes well beyond the raw schema and gives the agent the necessary context to invoke each parameter correctly.

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

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

The description opens with a clear, specific action: 'Open a saved workflow in the browser, as a tab in the ComfyUI window.' It distinguishes this tool from save_workspace and other workspace tools by explaining its role as the counterpart that loads saved workflow files into the UI.

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

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

It provides strong guidance on when to use this tool: it is the way to put a workflow file under workspace tools, and it explains why this capability matters when the user has no workflow open. It also gives explicit caveats about refusal when ComfyUI already knows the name, advises renaming or using 'force', and points to switch_workspace_tab as the follow-up for navigating tabs.

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

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

No annotations are provided, so the description carries the full burden. It clearly discloses that the tool only changes the user's view, does not affect the workflow, and is intentionally excluded from the undo stack to avoid ambiguity with Ctrl+Z. This is rich behavioral context beyond mere side-effects.

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

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

The description is well-structured: a one-sentence purpose, followed by usage context, a behavioral note, and an Args block. Every sentence earns its place, and the key information is front-loaded. No filler or redundant repetition of schema.

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

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

Given the tool's moderate complexity, the description covers purpose, usage guidance, parameters, side effects, and alternatives. An output schema exists, so return values need not be explained. The description is complete enough for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 0%, and the description fully compensates by explaining both parameters: 'to' takes 'root', 'up', or a subgraph node id; 'client_id' selects the tab and defaults to the most recently focused one. This is precise and actionable.

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

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

The description opens with a specific verb and resource: 'Move the ComfyUI canvas into a subgraph, back out one level, or to the top.' It clearly distinguishes this from sibling tools like get_workspace_graph (reading) and set_workspace_layout (layout) by emphasizing navigation scope.

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

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

Explicitly states when to use this tool versus alternatives: 'The other workspace tools take scope="active", so this is how to point them inside a subgraph. For reading alone it is usually unnecessary: get_workspace_graph(scope="all") descends without moving the user's view.' Also notes the undo stack behavior, which is a key usage consideration.

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

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

With no annotations to lean on, the description fully discloses behavior: it waits for the tab to register, explains the rationale for waiting, and warns about the side effect of opening a second tab (it becomes the preferred client and the user's tab silently stops being edited). It also details the meaning of the wait and force parameters. This is excellent transparency for an unattributed tool.

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

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

The description is longer than a one-liner but every sentence earns its place. It front-loads the core action, then logically explains the waiting behavior, the already-connected case, and parameter semantics. The structure is clear and the prose is tight, with no fluff or repetition.

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

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

The description covers the tool's role (fixing the no_workspace issue), its waiting semantics, the force edge case, and the side-effect of multiple tabs. Given the output schema exists and parameters are well-documented, there are no significant gaps. It even covers the failure mode that would otherwise confuse an agent: 'coming back before the page has loaded its JavaScript would just fail again.'

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

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

The schema only provides types and defaults, but the description's 'Args' section fully explains both parameters: wait is 'seconds to wait for the tab to connect. 0 returns as soon as the browser has been handed the URL' and force means 'open a tab even when one is already connected.' This adds crucial meaning beyond the schema, making the 0% schema description coverage irrelevant.

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

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

The description opens with a specific, actionable statement: 'Open ComfyUI in a browser, so the workspace tools have a tab to talk to.' It clearly identifies the resource (ComfyUI) and the action (open in browser), and distinguishes itself from sibling workspace tools by emphasizing it's the setup prerequisite for them. It's not a tautology and provides a clear purpose.

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

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

The description explicitly states when to use the tool: 'The bridge needs a page open - with none, every workspace_* tool fails with no_workspace and the only fix is a human opening one. This is that fix.' It even provides behavioral exclusions, such as leaving an already-connected tab alone and the caveat that using force can cause the user's own tab to silently stop being controlled. This goes beyond generic context.

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

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

With no annotations to rely on, this description carries the full burden of behavioral disclosure—and excels. It states the tool 'acts on the graph on screen' and that IDs do not survive in either direction, complete with concrete before/after examples (144/145 reused as 158/159). It also reveals the call order semantics (unpack before packing) and how invalid inputs are 'refused by litegraph', demonstrating deep transparency.

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

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

Though lengthy, the description earns its length: it's organized into short, scannable paragraphs with a clear logical flow (purpose → scoping → parameter nuances → caveats). The Args section is neatly formatted. Every sentence adds informative value, and the structure supports quick comprehension for an AI agent.

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

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

For a tool with no annotations and a generic schema, the description is remarkably complete. It covers edge cases (nested subgraphs, ID invalidation), specifies preconditions (call navigate_workspace first), details interactions with undo, and explicitly contrasts with a sibling operation that does not exist. No obvious gaps remain for an agent to misuse the tool.

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

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

The schema provides zero parameter descriptions, so the tool's Args section becomes critical. It explains that 'pack' expects node/group IDs and mentions what gets refused, 'unpack' identifies subgraph nodes to dissolve, and 'client_id' determines the target browser tab. This adds essential semantics beyond the bare union types in the schema.

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

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

The description opens with a precise verb-resource pairing: 'Wrap nodes and groups into a new subgraph, or dissolve one back out.' It immediately distinguishes the dual packing/unpacking behavior and grounds it in ComfyUI's 'Convert to Subgraph' and 'Unpack' concepts, making the tool's purpose unmistakable even to an agent familiar with the UI.

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

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

Explicit usage guidance is woven throughout: 'Use navigate_workspace first when the nodes are a level down' and 'This is not the same as moving a node into a subgraph that already exists...' The description clarifies when to use this tool over alternatives and even explains the workaround for a missing operate-on-existing-subgraph feature. It also sets expectations with 'One call is one Ctrl+Z'.

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

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

With no annotations, the description fully carries the transparency burden. It discloses what happens to widget inputs vs socket inputs, how ids map to both ends, atomicity ('Nothing is written unless every named input resolves'), skipped vs refused promote cases, and demote's disconnect-instead-of-remove behavior. This is far richer than typical tool descriptions.

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

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

The description is dense but every sentence earns its place. It front-loads the core action, then adds conceptual context, id semantics, atomicity, and organized parameter explanations. The Args block makes the parameter details scannable without redundant filler.

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

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

This is a conceptually complex tool involving nested subgraph ids, two input kinds, promote/demote operations, and atomic behavior. The description covers all of these, including edge cases like already-exposed inputs, wired inputs, and outer links surviving demotion. An output schema exists, so return-value details are not required.

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

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

The schema provides only bare object/string types with defaults, so the description is the sole source of meaning. It precisely defines the promote/demote shape as {"<subgraph node>:<node>": [names]}, explains skipped/refused outcomes, wired-input refusal, demote disconnection semantics, and client_id default behavior.

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

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

The opening sentence names the exact operation and resource: 'Expose an inner node's inputs on the face of the subgraph that holds it.' It further clarifies by distinguishing widget promotion from plain socket promotion and referencing ComfyUI's 'Promote widget', so the purpose is unambiguous and differentiated.

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

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

The description gives strong contextual guidance: sealed-box subgraphs need promotion to be usable externally, nested promotion is done step-by-step with shorter ids, and demote is the inverse operation. It does not explicitly contrast with sibling tools, but the unique purpose and clear examples make usage conditions evident.

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

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It discloses that the tool waits for tab registration, may be refused by the browser's 'Leave site?' dialog on unsaved edits, and that force writes the canvas to the export directory before reloading.

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

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

The description is appropriately sized and well-structured, with each paragraph serving a distinct purpose: the core action, the waiting rationale, the browser refusal edge case, and parameter details. It avoids redundancy and is front-loaded with the primary verb and resource.

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

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

The description covers all necessary context: the exact purpose, the failure mode when a page is half-loaded, the browser confirmation issue, the force fallback, and the client_id default behavior. Given the output schema exists, no return value explanation is required. The description is complete for this tool's complexity.

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

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

The description's Args section provides complete semantic meaning for all three parameters: wait seconds, force bypass confirmation, and client_id to select a tab. This fully compensates for the 0% schema description coverage.

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

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

The description clearly states the tool reloads the ComfyUI browser tab and waits for it to return. It explicitly defines the specific fix scenario (changed extension JavaScript) and distinguishes itself from restart_comfy by contrasting with node installation upgrades.

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

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

The description explicitly states when to use this tool (changed extension JavaScript) and when not to (node installation/upgrades requiring restart_comfy). It also provides an alternative (opening a second tab) and explains the force option for dealing with unsaved edits.

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

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

With no annotations, the description fully carries the behavioral disclosure burden. It explicitly reveals batch atomicity ('nothing is removed unless every id exists'), the single-undo-step behavior, and the side effect of unwiring attached links reported as `links_lost`. These are important, non-obvious behaviors that would otherwise be invisible to the agent.

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

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

The description is front-loaded with the core purpose, followed by essential behavioral caveats and parameter details. Every sentence earns its place; the structure with an Args section makes the parameter mappings easy to parse, and no content is redundant or fluff.

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

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

For a delete operation with side effects, the description is remarkably complete. It covers atomicity, undo grouping, the `links_lost` side effect, the alternative tool, and all parameter meanings. Although an output schema exists, the description still clarifies expected response content, making the tool fully understandable without needing to infer behavior.

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

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

Although schema description coverage is 0%, the Args section compensates completely by describing all three parameters. It states that `nodes` come from get_workspace_graph, explains the two `scope` values, and clarifies that `client_id` selects the browser tab with a sensible default. This is far more informative than the raw schema.

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

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

The description opens with a specific verb and resource ('Delete nodes from the workflow open in the browser'), making the tool's core action unambiguous. It also distinguishes this tool from the sibling set_workspace_node_modes by explicitly positioning deletion vs. bypassing, which prevents confusion.

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

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

The description gives clear when-to-use guidance: delete nodes when you truly want them removed, and prefer set_workspace_node_modes if you want to avoid unwiring. It also notes where node ids come from (get_workspace_graph) and explains the scope options, giving actionable context for choosing the right invocation.

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

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

With no annotations, the description carries the full burden and does so richly. It discloses side effects (schemas/model directories dropped), process handling (server-started vs self-started, bridge-node re-exec), persistence of browser tabs, and the force parameter's destructive effect on queued jobs. It also notes that a restart is the only way to reach a self-started process. No annotation contradictions exist.

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

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

The description is long but meticulously structured: it leads with the core action, then covers the 'when' (node vs JS), the 'how' (two mechanisms), the 'side effects' (schemas dropped, tabs reconnect), and finally the arguments. Every sentence conveys a distinct piece of decision-relevant information; none is wasted or redundant.

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

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

Given the tool's complexity (restart affects external process, UI state, and running work), the description covers all critical aspects: prerequisites (bridge node), side effects (schemas/models), workflow persistence, queued-job behavior, and parameter semantics. The output schema is not provided, but per instructions description needn't explain return values when an output schema exists.

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

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

Schema provides only types and defaults, with 0% schema description coverage. The description fully compensates by explaining 'wait: seconds to wait for ComfyUI to come back' and 'force: restart even with jobs running or queued, throwing that work away.' This adds meaning far beyond the raw schema fields.

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

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

The description opens with a specific verb+resource: 'Restart ComfyUI and wait for it to answer again.' It clearly distinguishes this from siblings like reload_workspace (which handles JS-only changes) and comfy_start/stop by naming the exact restart action focused exclusively on ComfyUI.

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

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

Provides explicit when-to-use guidance: a restart is needed for newly installed/edited node packs because nodes.py imports only at startup. It also names alternatives and exclusions: JS changes only need reload_workspace, and it explains the two restart mechanisms depending on process ownership, including the bridge-node prerequisite. This is far beyond a generic 'use this to restart'.

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

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

With no annotations, the description fully carries the behavioral disclosure burden. It covers return values, background execution behavior (wait=False returns prompt_id immediately), output persistence via save_outputs, and nuanced VRAM handling in free_on_switch (defaults and conditions). It even explains why low free VRAM is normal, demonstrating deep transparency.

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

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

The description is well-structured and appropriately sized for a complex tool. It opens with a one-sentence purpose, then gives a prerequisite, a seed tip, and a clear 'Args:' list. Every line adds value, with no fluff or repetition.

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

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

For a complex tool with 6 parameters and significant behavioral nuances, the description covers all important aspects: purpose, parameters, return behavior, side effects, and monitoring via get_progress. The availability of an output schema reduces the need to describe return structures in detail, and the description still mentions the top-level return type.

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

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

The input schema has no parameter descriptions (0% schema coverage), but the description explains every parameter in detail: name format, params with examples and raw key syntax, wait semantics, timeout, save_outputs conversion, and free_on_switch conditions/default. This fully compensates for the schema's lack of documentation.

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

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

The description clearly states 'Run a workflow and return the paths of the files it produced,' which uses a specific verb and resource while distinguishing it from sibling tools like run_workspace. It also mentions describe_workflow, reinforcing its role in the workflow run/inspect cycle.

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

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

The description provides explicit usage guidance: 'Call describe_workflow first' and 'Prefer this for anything slow' when deciding between wait=True and wait=False. It also warns against 'waiting blind,' which helps avoid misuse. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a perfect 5.

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

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

With no annotations provided, the description takes full responsibility for behavioral disclosure. It covers side effects (no writes to workflows directory), event mirroring behavior, widget callback execution (random seeds advance), graph non-rewriting, muted/bypassed node handling, and the rationale for omitting a params argument. This is exceptionally transparent and prevents surprising behavior.

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

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

The description is long but each paragraph contributes essential information about a tool with complex runtime behavior. The opening sentence is front-loaded with the primary action, and the structure (overview, behavioral nuances, rationale, args) is logical. Slightly verbose but every sentence earns its place.

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

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

Despite no annotations, the description covers all essential context: usage timing, side effects, edge cases (progress_mirrored failure, muted nodes), parameter semantics, and interaction with sibling tools. It even accounts for the output schema indirectly by referencing progress reporting. No critical gaps remain.

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

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

Schema description coverage is 0%, but the description's Args section fully compensates. Each parameter (wait, timeout, client_id) is explained with its effect, default, and behavioral implications (e.g., wait=false returns prompt_id and continues background watching). This far exceeds the bare schema.

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

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

The description opens with a clear, concrete action ('Press Queue Prompt in the browser and watch the run from here') and immediately differentiates from the sibling tool run_workflow ('Use this when the user is working on a graph in front of them; use run_workflow for a file'). This makes the tool's purpose unmistakable and contextually framed.

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

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

Explicit usage guidance is provided: when to use this tool versus run_workflow, and when to use set_workspace_values instead of passing params. It also advises preferring wait=false for slow runs to avoid mistaking a working generation for a hung one, giving clear decision rules for parameter choices.

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

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

With no annotations provided, the description carries the full burden. It explains the behavioral differences between 'ui' and 'api' formats, overwrite semantics, scope options, and the nature of the reply ('a path and a few numbers'). It does not mention permissions or side effects, but for a save operation this is adequate.

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

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

The description is appropriately sized and front-loaded. The opening sentence states the core action, followed by rationale, then a structured Args list. Every sentence contributes useful information; there is no redundancy or filler.

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

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

Given the tool's complexity (5 parameters, no annotations), the description is remarkably complete. It covers purpose, use cases, format distinctions, scope, overwrite, and even the response shape. It also relates to sibling tools (run_workflow, describe_workflow) to ground its context.

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

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

Schema coverage is 0%, so the description must compensate. It does so thoroughly with an Args section explaining each parameter: 'name' (file name), 'format' (ui vs api with detailed consequences), 'scope' (root vs active), 'overwrite' (replace file), and 'client_id' (which tab to ask). This adds meaning far beyond the schema's bare property names.

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

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

The description opens with a specific verb and resource: 'Write the workflow open in the browser to a file.' It clearly distinguishes from siblings like load_workspace and open_workspace. The additional context about handling large graphs further clarifies the tool's unique role.

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

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

It provides clear use cases ('This is how to get at a graph too large to fit in one answer' and 'how an unsaved canvas becomes something that survives the tab being closed'). It also explains format-specific destinations, implicitly guiding when to use 'ui' vs 'api' in relation to run_workflow and describe_workflow. No explicit 'when not to use' is given, but context is strong.

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

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

With no annotations provided, the description fully carries the transparency burden. It discloses a critical limitation: HTML overlays (prompts, previews, notes) are not captured, and states that an empty-looking prompt box does not reflect the prompt. It also explains that max_edge affects legibility and cost, and that the default client_id is the most recently focused tab.

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

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

The description is well-structured with a clear introduction, explanation of limitations, and an Args section. Every sentence earns its place, providing necessary context without fluff. It is front-loaded with the core purpose and then expands into actionable details.

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

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

Given the tool has no output schema, the description adequately sets expectations about outputs (a picture of the canvas, plus a report mentioning widget count and graph name). It also covers all parameters and scenarios (entire graph, subgraph, viewport, selected nodes) making it sufficiently complete for an agent to invoke correctly.

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

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

The input schema has 0% description coverage, but the description compensates fully. Each parameter is explained with concrete meanings, examples, and usage guidance: fit options and their visual implications, max_edge range and trade-offs, format rationale for crispness vs. size, and client_id default behavior. This adds substantial value beyond the raw schema.

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

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

The description opens with a clear verb and resource: 'Photograph the ComfyUI canvas' and immediately distinguishes its purpose from graph dumps by highlighting what visual information it captures (overlaps, crossing links, layout mess). This directly addresses the tool's role among siblings like get_workspace_graph.

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

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

The description provides explicit guidance on when to use this tool: 'After a layout change it is the only way to check the result rather than assume it.' It also names alternatives and exclusions: get_workspace_graph for reading values, navigate_workspace to frame subgraphs. This gives clear context for choosing between tools.

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

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

With no annotations provided, the description fully discloses behavioral traits: groups hold no membership, deleting only removes the box, nodes stay in place, create refits the box to nodes with padding, update can refit the box, and empty groups need an explicit bounding box. This exceeds annotations by providing concrete side-effect information.

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

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

The description is well-structured with a short lead sentence followed by detailed yet efficient explanations. It uses an Args block for parameter details. Every sentence adds value—there is no fluff. The length is justified by the tool's complexity.

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

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

Given zero annotations and zero schema description coverage, the description thoroughly covers all necessary context: what the tool does, how each operation variant works, parameter formats, defaults, and pointers to related tools. The presence of an output schema reduces the need to describe return values, so the description is complete for an agent to use.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it succeeds. It explains each parameter in detail with examples ('create: [{"title": ..., "nodes": ["3", "8"]}]'), defaults ('padding 10', 'scope: root', 'client_id defaulting to most recently focused'), and clarification on behavior ('refit around these', 'refit around whatever it currently holds'). This goes well beyond the minimal schema.

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

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

The description opens with 'Create, edit and delete the group boxes on the canvas open in the browser.' This uses a specific verb set and clearly identifies the resource (canvas groups), distinguishing it from sibling tools like set_workspace_selection or set_workspace_layout. The sentence directly conveys the tool's purpose and scope.

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

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

The description implicitly guides usage by defining when to use it ('creating one around a list of nodes') and mentioning related tools ('Get the current groups, with their ids and members, from get_workspace_graph'). It does not explicitly state when not to use it or list alternative tools, but the contextual guidance is sufficient.

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

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

With no annotations, the description carries full responsibility and excels. It discloses atomicity ('The whole batch is one undo step and nothing is written unless every id exists'), group behavior ('membership is read before anything moves and each affected group is refitted around those same nodes afterwards'), pinning behavior ('A pinned node is skipped rather than moved, and reported in `skipped`'), and idempotent collapsed semantics ('asking for what a node already is does nothing'). These are non-obvious traits that would affect invocation.

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

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

The description is longer than average but front-loaded with the core purpose and caveat that workflow behavior is unchanged. The Args section is dense but each sentence adds value – no fluff. It could be slightly tightened, but the complexity of group behavior and multiple parameters justifies the length.

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

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

The description covers all six parameters, explains edge cases (pinning, minimum sizes, empty groups), describes side effects (undo step, atomic validation), and references related tools (arrange_workspace, get_workspace_graph). With an output schema present, the lack of return-value detail is acceptable. The tool is fully contextualized for an agent.

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

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 compensate. It explains every parameter in detail: positions with coordinates and pinning, sizes with minimum raising, collapsed as desired state not toggle, refit_groups with rationale, scope values, and client_id default. This goes beyond simple type information to provide actionable semantics.

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

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

The description opens with a specific verb+resource: 'Move, resize, fold and unfold nodes on the canvas open in the browser.' This clearly distinguishes it from siblings by listing concrete operations and later references arrange_workspace for computed positions, making the tool's unique role obvious.

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

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

The description states when to use it: 'purely about making a graph readable' (layout vs workflow semantics) and explicitly names an alternative: 'arrange_workspace computes positions rather than taking them, and its answer can be passed straight in here.' It also mentions get_workspace_graph for reading current collapsed state, offering clear contextual guidance.

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

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

With no annotations provided, the description fully discloses critical behavioral traits: the atomic undo step, disconnect-first ordering, input replacement behavior, type compatibility checks that silently do nothing on mismatch, and the meaning of scope and client_id. This goes well beyond basic expectations and is highly transparent.

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

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

The description is appropriately detailed for a complex tool, with each paragraph serving a distinct purpose. It is front-loaded with the main action, then explains behavior, parameter formats, and edge cases. No redundant or filler content; every sentence adds value.

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

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

Given the tool's complexity and lack of annotations, the description covers the operation, atomicity, failure behavior, and parameter nuances comprehensively. The presence of an output schema makes it unnecessary to detail return values, and the description is complete for accurate invocation.

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

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

Schema description coverage is 0%, so the description must compensate, and it does thoroughly. Connect format is explained with examples ('8.IMAGE', '8.0'), disconnect is clarified as input-only with reasoning, scope is defined, and client_id default is stated. This fully covers all four parameters with added semantic clarity.

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

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

The description opens with 'Wire and unwire nodes in the workflow open in the browser,' which clearly identifies the specific action (wiring/unwiring) and resource (workflow nodes). This distinguishes it from sibling tools like set_workspace_values or set_workspace_groups, which target different aspects of the workspace.

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

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

The description provides clear context on when to use the tool (for wiring/unwiring nodes) and explains the scope parameter (root vs active), but it does not explicitly name alternatives or state when not to use it. The context is strong, but the lack of explicit exclusions prevents a 5.

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

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

With no annotations provided, the description carries the full burden and excels. It explains the behavioral difference between 'muted' and 'bypassed' with concrete examples ('stops a node producing anything' vs 'passes its inputs straight through') and discloses atomicity ('the whole call is one undo step') and validation behavior ('nothing changes unless every entry is valid'). This is comprehensive disclosure beyond simply stating the action.

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

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

The description is well-structured and every sentence earns its place. It opens with a clear statement of purpose, then defines key terms, notes atomicity, and lists arguments with meaningful descriptions. It is appropriately sized for a tool with three parameters and a non-trivial modes object.

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

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

Given the tool's moderate complexity and the presence of an output schema (which handles return values), the description is complete. It covers all parameters with semantics, explains the core concepts, and provides usage context. The atomicity and validation behavior are disclosed, leaving no obvious gaps for an agent to select or invoke it correctly.

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

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. It defines the exact format for modes (`"{\<node_id\>: \"always\" | \"muted\" | \"bypassed\"}"`), explains scope values ('root' vs 'active'), and provides the default behavior for client_id. This adds significant meaning beyond the bare schema structure.

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

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

The description clearly states the tool's purpose: 'Mute or bypass nodes in the workflow open in the browser.' It distinguishes itself from sibling tools by explaining the specific semantics of muted and bypassed states and how they help narrow a workflow. The reference to set_workspace_values for atomicity further positions it within the workspace tool family.

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

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

The description provides clear context for when to use this tool: 'Both are how a workflow gets narrowed to the part being worked on.' It implies usage where temporary node deactivation is needed without unwiring, but does not explicitly state when not to use it or point to alternatives like remove_workspace_nodes. This is a clear context with no exclusions, fitting the 'no exclusions' criteria.

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

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

With no annotations, the description fully discloses important behavioral traits: selecting nothing clears the selection, selection is not part of the workflow and thus not on the undo stack, and Ctrl+Z will not revert it. It also explains the 'add' parameter semantics and the default for 'centre,' providing a clear mental model of the tool's effects.

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

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

The description is well-structured and front-loaded with the core purpose in the first sentence. Every paragraph earns its place: the rationale, the usage guidance, the behavioral caveats, and the parameter explanations are all relevant and non-redundant. The length is appropriate for a tool with five parameters and several subtleties.

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

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

The description is complete for the tool's complexity: it covers purpose, usage timing, side effects, relationship to the undo stack, and parameter specifics. It even instructs on prerequisite actions like navigate_workspace. With an output schema present, explaining return values is unnecessary, and none of the important operational aspects are left ambiguous.

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

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

The description includes an explicit 'Args' section that explains each of the five parameters beyond the bare schema. For 'nodes,' it adds critical details about IDs being local to the visible graph and dropping prefixes like '98:12' after navigating into a subgraph. It also clarifies the semantics of 'add' and 'centre' defaults, which the schema leaves ambiguous.

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

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

The description opens with a clear, specific purpose: 'Highlight nodes and groups on the canvas, so the user can see which ones you mean.' It distinguishes the tool from siblings by calling it 'the write half of what get_workspace_graph reports as selected,' clarifying its role relative to a related read tool. The verb 'set' and resource 'workspace selection' are explicit.

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

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

The description gives explicit when-to-use guidance: 'Use it before an edit the user should agree to, and to answer "which ones?" without a list.' It also offers context on the read/write pairing with get_workspace_graph and advises calling navigate_workspace first for subgraphs. No alternatives are excluded, but the intended use cases are clearly delineated.

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

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

With no annotations provided, the description carries the full burden and does so exceptionally. It discloses the undo-stack single-step behavior, all-or-nothing validation, numeric range enforcement, the note-and-write behavior for out-of-list combo values, label persistence (not saved with workflow), the localized_name caveat, and setProperty mechanics. This is far beyond typical transparency.

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

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

The description is long but front-loaded with a one-sentence summary and a clean Args section. Most sentences add valuable behavioral or usage detail, but a few asides (e.g., the Chinese-language example) are somewhat tangential and could be trimmed without losing core information. Overall it is well-structured and dense, but not perfectly concise.

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

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

This is a complex tool with 5 parameters, and the description covers all of them thoroughly, including side effects, validation, undo behavior, persistence, and edge cases. It references get_workspace_graph for IDs. Since an output schema exists, not explaining return values is acceptable. This is a complete and self-sufficient description for the tool's complexity.

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

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

Schema description coverage is 0%, and the description fully compensates. For every parameter it gives detailed semantics: values format and example, properties explanation with collision warning, labels structure with override-clearing and persistence caveats, scope meaning, and client_id default. It even explains why labels are keyed by node id alone—far more than the schema provides.

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

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

The description opens with a specific verb+resource+scope: 'Set widget values, node properties and on-screen labels in the open workflow.' It clearly distinguishes from sibling tools like set_workspace_layout (layout), align_workspace (alignment), and set_workspace_node_modes (modes) by naming exactly what is being changed and where.

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

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

It provides clear context: the tool edits the live canvas exactly as if typed, and explicitly explains why to pass several values at once and why properties live here rather than a separate tool. It also references get_workspace_graph for node ids and widget names. However, it does not explicitly state when NOT to use this tool versus alternatives, so it stops short of a full when/when-not specification.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the downscaling behavior ('downscaled to keep it small') and that it returns an image for viewing, which are useful. However, it does not describe the return format, potential errors, or any side effects, leaving some behavioral aspects unspecified.

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

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

The description is concise, with two sentences for the purpose and behavior, followed by a clear Args block. It is front-loaded with the main purpose and contains no filler or redundant information.

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

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

For a simple tool with only two parameters and no output schema, the description provides sufficient context: how to obtain the path (from run_workflow), what max_edge does, and that the image is downscaled. It omits details like return format or error conditions, but these are not critical given the tool's simplicity and the absence of annotations.

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

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

Schema description coverage is 0%, so the description must compensate for explaining parameters. It does so thoroughly: 'path' is explained as a path from run_workflow's outputs, and 'max_edge' is explained as the longest edge in pixels after downscaling. This fully adds meaning beyond the raw schema.

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

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

The description clearly states the tool returns a generated image for viewing, with a specific verb ('Return') and resource ('generated image'). It distinguishes itself from sibling tools by referencing 'run_workflow's outputs', making its role unique among the listed tools.

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

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

The description provides clear context for when to use the tool: after running a workflow, to view a generated image by specifying a path from run_workflow's outputs. It does not explicitly exclude alternatives, but the reference to run_workflow gives enough contextual guidance for an agent to select it appropriately.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: switching reloads the canvas from that workflow's stored state, unsaved edits are not lost, 'force' reloads the current tab, and ambiguous names are refused. It even states 'Switching does what clicking the tab does, and no more', setting accurate expectations.

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

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

The description is well-organized with front-loaded purpose and an Args list. While slightly verbose, every sentence adds useful context, such as clarifying how 'new' works and the relationship with workspace_status. It earns its length, though a minor trim could improve conciseness.

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

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

Given the tool's complexity (multiple parameter value types, edge cases) and lack of annotations, the description is remarkably complete. It covers all parameters, ambiguous name handling, the 'new' action, and the interaction with other workspace tools. An output schema exists, so return values need no explanation.

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

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

Schema description coverage is 0% and parameters lack descriptions, but the description's 'Args:' section fully compensates. It explains the semantics of 'to' (index, path, filename, special keywords), 'force', and 'client_id', adding rich meaning beyond the bare schema types and defaults.

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

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

The description clearly states the tool's purpose: 'List the workflow tabs open in the ComfyUI window, and switch between them.' It specifies the resource (workflow tabs in ComfyUI) and distinguishes itself from browser tabs and other workspace tools, making it unambiguous and well-differentiated from siblings.

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

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

The description provides explicit usage guidance: it explains when to use the tool (to point other workspace tools at a different workflow), how to discover open tabs (call with no 'to'), and when to use 'new'. It also contrasts with 'Every other workspace tool', giving clear alternatives.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses bracketing (batch edits come back in one undo), interleaving of user history, redo history clearing on next edit, and the silent no-op on empty history. This goes far beyond what the schema or annotations could convey.

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

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

The description is well-structured with a one-line summary, a critical warning, and a clear args list. Every sentence adds value—from the Ctrl+Z analogy to the interleaving caveat to the redo behavior. It is appropriately sized for the tool's complexity and front-loaded with the core purpose.

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

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

Given the tool's moderate complexity and no annotations, the description is remarkably complete. It covers the main behavior, edge cases (empty history, steps=0), redo semantics, and client scoping. The output schema exists, so return values need not be described. No obvious gaps remain.

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

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

Schema description coverage is 0%, so the description must explain the parameters, and it does so completely. It defines steps (1-50, with 0 as a special depth check), redo (step forward, cleared by next edit), and client_id (which tab, defaulting to most recently focused). Each parameter receives meaningful behavioral context that the bare schema lacks.

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

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

The description opens with a specific verb and resource: 'Undo the last edit in the browser, exactly as Ctrl+Z would.' This clearly distinguishes it from sibling tools that set, run, or load workspace state. It also immediately conveys the tool's scope and user-facing analogy.

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

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

The description explains when to use undo (to cheaply take back wrong edits) and even warns about caution when stepping back multiple times ('several steps back is taking back whatever was there, theirs included'). It also describes redo usage. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It discloses the core behavior (uploads to input folder, returns a name for LoadImage) but does not mention overwriting behavior, file format limitations, or how the subfolder parameter affects the upload. This is adequate but not rich.

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

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

The description is two concise sentences, front-loaded with the main action and purpose. No redundant or filler content.

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

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

For a simple upload tool with an output schema present, the description covers the essential behavior and return value. It lacks parameter details and edge-case disclosures, but the tool's complexity is low, and the description is sufficient for basic invocation.

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

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

Schema description coverage is 0%, and the description does not explain either parameter. 'path' is somewhat inferable as the local file path, but 'subfolder' is entirely unexplained, including its relationship to the input folder and how it affects the returned name.

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

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

The description clearly identifies the action: 'Upload a local image into ComfyUI's input folder'. It names the specific resource (local image, input folder) and the purpose ('so workflows can load it'). This distinguishes it from siblings like show_image or list_models.

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

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

The description implies when to use the tool: when you need to make a local image accessible to ComfyUI workflows. It doesn't explicitly state when not to use it or name alternatives, but the context is clear enough for a simple upload operation.

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

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

With no annotations, the description carries the full burden. It explains the core behavior (reports which prerequisite is missing) and the additional capability (client_id discovery). It implicitly indicates a read-only check, but does not explicitly state side-effect-free behavior or behavior when ComfyUI is not running, which would push it to a 5.

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

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

The description is three sentences total: a clear purpose statement, a brief explanation of prerequisites, and a usage directive. Every sentence carries necessary information with no waste.

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

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

For a zero-parameter diagnostic tool with an output schema, the description fully covers the tool's purpose, prerequisites, and recommended usage. It tells the agent what the workspace refers to, what conditions are needed, and how to use the results.

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

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

The tool has zero parameters, so the schema is trivially complete. The baseline for 0-param tools is 4, and the description logically explains the state being checked without needing parameter details.

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

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

The description uses a specific verb ('Check whether') and resource ('live ComfyUI workspace'), defining what the workspace is. It clearly distinguishes itself from siblings by explaining it reports which prerequisite (bridge node/tab) is missing and can find client_id values, which is unique among the listed tools.

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

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

Explicit guidance is given: 'Call it before the other workspace_* tools when they fail' and 'to find client_id values when several tabs are open.' This tells the agent exactly when to use this tool versus alternatives.

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