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

Even with annotations declaring readOnlyHint, openWorldHint, and idempotentHint, the description adds behavioral context beyond them: it never raises, a down instance is a failed check rather than an error, and it explains the gate ('ok gates on ComfyUI reachable') and soft checks ('relocation is a soft check surfaced via hint'). This is substantial value beyond the 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 dense but efficient: three sentences cover purpose, usage guidance, behavioral guarantee, and return shape. It front-loads the core diagnostic role and avoids fluff, making it easy for an agent to parse quickly.

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?

With no parameters and a rich output schema, the description still provides the non-obvious context: what the checks mean, how to interpret the response gates, and how it behaves on a down instance. Combined with the annotations and output schema, an agent has everything needed to correctly invoke and interpret 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?

There are zero parameters, so no parameter semantics are needed. The description adds meaning by detailing what the diagnostic checks and how the results are structured, which effectively covers the absence of parameters.

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 is a 'one-shot setup diagnostic' and enumerates the exact three checks: ComfyUI reachability, render handoff via COMFYUI_MOUNT_DIR, and partner-node key presence. It explicitly contrasts itself with get_instance_info, making the agent able to discriminate the tool from siblings without inspecting the schema.

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 says both what the tool is for ('fresh install or a sandboxed client (Cowork/Desktop/Code)') and gives concrete when-to-use guidance: 'run it first when a render can't be delivered or the instance seems unreachable.' It also provides an exclusion by contrasting with get_instance_info, which raises on a down instance.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the two creation modes and the return contents (workflow_id + node summary), but says nothing about persistence, where the workflow is stored, or what happens if the template name is invalid. With annotations carrying the burden, a 3 is appropriate.

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 compact sentences with no filler; the creation modes and template recommendation are front-loaded, and the return-value note is appended efficiently. Slightly dense parenthetical, but nothing is wasted.

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?

An output schema exists, so the return-value contract does not need elaboration, and the description correctly avoids over-explaining it. Both creation paths and the pointer to list_templates make it sufficient for a two-parameter create tool, with only the title parameter left implicit.

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 two parameters. It explains the template parameter's purpose (seeding from a bundled template) and points to list_templates for valid values, but the required title parameter is never addressed and no format constraints are given. Partial compensation only.

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 gives a clear verb+resource ("Start a workflow") and immediately distinguishes the two creation modes: blank or seeded from a bundled template. It is specific about the outcome and mentions the returned workflow_id, though it does not explicitly name how it differs from sibling save_workflow or import_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?

It states a clear recommendation ("seeded from a bundled template (recommended for current model families)") and routes the agent to the sibling tool list_templates for the template list. There is no explicit when-not-to-use guidance or comparison against save_workflow/import_workflow, which keeps it 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?

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds transparency by stating that the tool only proposes fixes and that actual modification should happen through edit_workflow or port_workflow, which is consistent with the annotations and extends the 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 dense but short: two sentences, with the primary purpose front-loaded and follow-up routing placed at the end. Every clause earns its place without wasting the agent's attention.

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 read-only diagnostic tool with one obvious parameter and an output schema, the description gives enough guidance for correct invocation and follow-up. It clarifies relationship with validate_workflow, edit_workflow, and port_workflow, so the agent can decide when and how to use it.

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?

There is only one parameter, workflow_id, and its name plus schema type already make the meaning obvious. Although schema description coverage is 0%, the low parameter complexity and the repeated workflow context in the description reduce the impact of having no additional parameter-level explanation.

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 concrete verb ('Deep-check') and identifies the exact resource ('workflow') and the expected outcome ('propose fixes'). It explicitly positions itself as a superset of validate_workflow and adds Comfy Registry resolution for missing custom-node classes, making it easy to distinguish from 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 gives clear selection context: use this for old/broken workflows that need deeper diagnosis and repair proposals, and it routes follow-up actions to edit_workflow or port_workflow for model-family moves. It does not explicitly say 'when not to use this tool', but the superset relationship with validate_workflow, plus the explicit alternatives makes the usage boundary fairly 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?

Substantially exceeds what the annotations declare: atomicity ('all or nothing — a failing op changes nothing'), live type checking of widgets and links, the 'force': true override and its side effect of creating frontend-only inputs, and the delta-vs-full-graph return behavior with summary=true. These are exactly the operational facts an agent needs before issuing a batch and are not available in structured fields. Minor tension: destructiveHint=false while remove_node/remove_group genuinely delete nodes and links, though this is arguably reversible graph editing rather than a hard contradiction.

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?

Front-loaded with the core action, then organized as a scannable per-op reference where each line earns its place by defining one operation. Some passages are over-compressed to the point of ambiguity, notably the run-on 'Subgraph twins add ...' sentence which requires re-parsing to determine the mapping between base ops and their _in_definition variants.

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?

An output schema exists, so not explaining return values is appropriate, and the description still usefully clarifies delta vs. full graph. Coverage is strong for a 12-plus-operation batch tool, with the main omission being how to obtain a valid workflow_id and what happens on failure beyond the all-or-nothing guarantee.

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 carry the load — and it does, effectively serving as the real spec for the operations array, including per-op required fields and semantics like 'replaces a link' on connect and 'must match once' on replace_in_widget. The offsetting gap is workflow_id, which is never explained (format or source), and summary's effect is only mentioned in passing at the end.

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, 'Apply batched edits,' pairs a specific verb with a clear resource (a workflow graph), and the enumerated op list makes the scope unmistakable. It does not, however, explicitly distinguish itself from siblings like create_workflow or save_workflow, so an agent must infer the boundary between editing an existing graph and creating/persisting one.

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?

Usage is implied by the op grammar rather than stated: there is no 'use this when...' guidance and no explicit alternatives for graph mutation. The single routing hint present ("organize_workflow redoes all layout") is a caveat, not a when-to-use rule, so the agent must derive selection criteria on its own.

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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds behavior beyond that: 'ui' preserves layout and notes, and passing path has a side effect of writing to a file, after which the dict reports saved_to instead of embedding the graph. That file-write side effect is genuinely useful context not present in the 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?

Two short passages, front-loaded with the format distinction before the optional path behavior. Every clause carries information; nothing is redundant with the schema or annotations.

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 three-parameter tool with one enum and an existing output schema, the description covers format semantics and the path side effect, which is what an agent needs to call it correctly. Return shape details are legitimately delegated to the output schema.

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 burden and largely does: it explains both 'ui' and 'api' enum values with their purposes and explains path as an optional file-write target with its effect on the response. Only workflow_id is left implicit, which is self-evident.

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 names the resource (the workflow) and specifies the two output variants ('ui' vs 'api') with concrete distinguishing traits (layout & notes vs POST /prompt automation). The export verb itself is implicit from the name rather than stated, but an agent can tell what it produces. Sibling tools like save_workflow and port_workflow are not contrasted, so differentiation is partial.

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 real selection guidance at the format level ('ui' for editor-shareable, 'api' for automation via POST /prompt) and explains what passing path does. However, it never says when to reach for this tool instead of siblings such as port_workflow or save_workflow, so usage 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?

Annotations already cover readOnly/idempotent/openWorld safety, and the description adds real context beyond them: output is a few RANKED summaries (not full graphs), sourced from saved JSON including hand-built ones, with a named load path. It doesn't mention ranking criteria or result-count behavior beyond the limit param, keeping it short of 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?

Front-loaded with the core value proposition and efficient throughout, though the parenthetical list of summary fields and the double aside ('hand-built ones included') make it slightly denser than needed.

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?

Output schema exists, so return-value detail is optional, yet the description still characterizes the response (family, base model, resolution, tags, match reason) and the load path. The only gap is the undocumented limit parameter.

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 well for 'intent' by explaining natural-language phrasing and giving a concrete example, but 'limit' is never mentioned in the description and has no schema description, leaving one of two parameters fully undocumented.

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 (find) and resource (saved workflows) plus the goal-oriented input style, and explicitly distinguishes itself from list_workflows and import_workflow. An agent can tell what it returns (ranked summaries) without opening the schema.

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 when-to-use ('reuse beats rebuilding', prefer this over importing each result of list_workflows) and names the follow-up alternative (import_workflow(name=...)) plus the rule that this never returns full graphs. Routing is unambiguous.

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?

Annotations already declare readOnly, idempotent, and openWorld behavior. The description adds useful behavioral context by specifying that the relocation block reports whether COMFYUI_MOUNT_DIR is set and writable, and what the consequence is when it is not. This goes beyond what annotations alone 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 short and front-loads the concrete output fields before giving the call-order and relocation caveat. Every sentence earns its keep, though the final sentence could be trimmed without losing meaning.

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?

With no inputs and an output schema, the description only needs to clarify when to call the tool and what to do with a critical result. It does both, including concrete reasons for checking relocation readiness before starting render work.

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 zero parameters, so the 0-parameter baseline of 4 is appropriate. There are no parameters for the description to document, and it correctly focuses on what the returned metadata means.

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 enumerates the exact data returned: ComfyUI version, OS, VRAM, queue length, and render-relocation readiness, and additionally says to call it first. This is clear even though it lacks a full verb phrase, and the 'Call first' instruction gives it a distinct role among 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 gives explicit when-to-use guidance: call this tool first, and before spending a render, surface the relocation readiness issue to the user. It does not explicitly name or exclude alternatives, so it misses the highest level of routing 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?

Annotations cover safety (readOnly, idempotent, openWorld), but the description adds real conditional behavior: a learned overlay from past research may be merged in, a research directive may be present, and the `fit` block appears only when this GPU cannot hold the model. That conditional-output disclosure is exactly what an agent needs and is not derivable from structured fields.

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?

Front-loads what the tool returns, then moves to usage and conditional behaviors. Four sentences, all information-bearing; slightly dense but no 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?

An output schema exists, so return values need not be restated, and the description covers the conditional blocks, overlay, and directive well. The remaining gap is the sibling-relationship and `family` parameter semantics, which matter 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%, so the description carries the burden. It explains model_filename's behavior (alone it detects the family and applies turbo/lightning/distill overrides) but says nothing about `family`, its relationship or precedence relative to model_filename, or accepted filename formats.

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 resource and enumerates its contents (sampling settings, native resolutions, technique blocks, prompt style notes), which tells an agent exactly what this returns versus generic siblings like get_node_info or list_models. It never names a sibling for contrast, so it falls short of the top band.

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 concrete invocation guidance — passing model_filename alone triggers family detection and variant overrides — and routes the agent to record_learning for brand-new models. No explicit 'do not use when' or alternative-tool comparison, so it stops short of 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?

Annotations already declare readOnly/openWorld/idempotent, so the safety profile is covered. The description adds real behavioral detail beyond them: the dual return shape (dict keyed by class_type when batching vs. direct schema for a single class_type) and the 24-choice truncation cap with its escape hatches.

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?

Front-loaded with the purpose, then two tight paragraphs on batching and combo browsing. Slightly redundant in restating the batch-vs-single behavior twice, but every sentence is actionable.

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?

An output schema exists, so return values need not be explained, yet the description usefully documents the two return shapes. For a read-only lookup tool the coverage is strong; only edge behavior (e.g., unknown class_type) is unaddressed, which is minor.

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 does so: class_types is explained with a concrete example and its keyed return shape, class_type is contrasted against it, choices_filter is given syntax ('substring' or 'input:substring', case-insensitive), and max_choices is tied to raising the cap.

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+resource: retrieves the full input/output schema (slot names, types, widget defaults/ranges, combo choices, tooltips) for node classes. It is clear what the tool returns, but it never distinguishes itself from the close siblings search_nodes and search_node_packs, so an agent must infer the boundary.

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 concrete operational guidance: batch lookups via class_types to fetch many in one call instead of one call per node, and use choices_filter/max_choices to browse combo lists beyond the default 24. It does not say when to prefer this over search_nodes, 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?

Annotations already establish readOnly/idempotent/openWorld, but the description adds genuine behavioral detail beyond them: what the response contains at each stage (queue position, live step progress while sampling, outputs plus error details and elapsed_s once finished). That is useful state-machine context for a polling 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?

Front-loads the essential routing information (queued with wait=False) in the first sentence, then details the return shape. Mildly dense but every sentence carries information; no 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?

An output schema exists so return values needn't be detailed, yet the description usefully summarizes lifecycle stages anyway. For a 2-param polling tool with annotations covering safety, the only real gap is the unexplained required `prompt_id`.

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 carry parameter meaning. It explains `full_output=<node_id>` returns that node's text unclipped, which is real added value, but `prompt_id` — the required parameter — is never explained or tied to the run queue.

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 (poll status of a run) and ties it to a precise scope: runs queued with `run_workflow(wait=False)`. This scoping distinguishes it from siblings like get_node_info, get_instance_info, and view_output without opening any schema.

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 says this is for runs queued with `run_workflow(wait=False)` and points to `run_workflow`'s long-render pattern for long/paid renders, giving real when-to-use context. It stops short of explicit when-not/exclusion rules and the alternative reference is left as a pointer rather than spelled out.

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?

Annotations only declare readOnlyHint=false, openWorldHint=false, destructiveHint=false, which is a thin behavioral profile for a tool that mutates session state. The description compensates by disclosing the mutual-exclusion constraint and the cost tradeoff (name preferred for large files, no pasting), plus the accepted JSON shapes. It stops short of stating what happens on import failure or whether the session is replaced, so it is strong but not exhaustive.

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 opening sentence states the action; the middle is a scannable bullet list of mutually exclusive options; the closing sentence states intended uses. No filler, and the critical exactly-one constraint is front-loaded before the options.

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?

An output schema exists, so return values need no explanation, and the description covers the source-selection logic and accepted formats well. What is missing is failure behavior: what happens if none or more than one source is provided, or if the JSON is malformed. Given four optional parameters with no required fields, that enforcement detail is the one thing an agent most needs, so the definition is complete but not airtight.

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 does: each of the four parameters' roles is explained, including two accepted JSON formats for workflow_json (UI nodes/links vs API {id: {class_type, inputs}}) and the source of name (ComfyUI's workflow browser, cross-referenced to list_workflows). Only the 'title' parameter is left unexplained, which is a minor gap against an otherwise complete mapping.

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 ('Import an existing workflow into the session') and immediately distinguishes the action from siblings like create_workflow or find_workflow by scoping it to loading existing work. It even names downstream uses (beautifying/diagnosing/porting), which helps the agent place it against inspect_workflow, diagnose_workflow, and port_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?

Explicitly enforces the exactly-one-source rule with 'Provide exactly ONE source' and enumerates the three mutually exclusive options, including which is preferred for large files. This is far more than implied guidance and directly prevents a class of invocation errors.

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?

Annotations already carry readOnlyHint, openWorldHint=false, and idempotentHint=true. The description adds meaningful behavioral detail by specifying the compact scope and the fact that subgraph definitions can contain full inner node/wiring detail.

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 compact sentence packs in purpose, content, and the subgraph caveat without redundant words. Front-loaded key phrase 'Compact view of a session workflow'.

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?

With one simple parameter and an output schema present, the description provides enough for immediate use: it describes the structural view, node details, group views, and subgraph coverage. It does not provide parameter lookup guidance, but this is minor given the 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?

Schema coverage is 0%, so the description carries full responsibility for parameter meaning. Although workflow_id's purpose is inferable from the tool name, the description adds no explicit detail about the parameter's format, origin, or relationship to resources like list_workflows.

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 a compact inspection view of a session workflow, enumerating what is included (nodes, links, groups, and subgraph detail). This distinguishes it from siblings like get_node_info or search_nodes that cover only a narrow portion of workflow structure.

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: use this tool to get a compact structural overview of a workflow, with expanded detail for subgraph definitions. It implies when the tool is appropriate but does not explicitly name alternatives or conditions 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?

The annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering safety and side effects. The description adds useful behavioral context: it returns an empty list when clean, it detects orphan nodes, unconnected inputs, empty list means clean, and it narrows the alignment check to families with a known alignment requirement. No contradiction with 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 tight, front-loaded, and information-dense. 'Readability/wiring lint:' establishes the purpose, a concise list defines scope, and 'Empty list = clean.' closes with an unambiguous contract. There is no 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?

For a single-parameter read-only lint with an output schema, the description covers the necessary behavioral and scoping details well. The only contextual gap is the undocumented workflow_id parameter semantics, which keeps it from being fully 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 input schema only says workflow_id is a required string, with 0% description coverage. The tool description does not explain what a workflow_id should look like, where to obtain it, or how it is used in the lint. The parameter name provides a minimal hint, but the description fails to compensate for the empty schema description.

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 the verb and resource precisely: a readability/wiring lint. It then enumerates the specific classes of issues it detects, which strongly separates it from generic validation or diagnostic 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 clearly scopes the tool to readability and wiring concerns by naming concrete lint categories, so an agent can infer when to use it. It does not explicitly or alternately, but the sibling names like validate_workflow and diagnose_workflow make the distinction fairly obvious.

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 annotations already signal read-only, idempotent, and open-world behavior, so the description adds real value by explaining conditional behavior: unknown folder values produce the full list, search is case-insensitive substring matching, and metadata_for switches from listing to embedded training metadata. These are precisely the behaviors an agent would not infer from the schema or 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 compact and front-loaded with the primary purpose. Each sentence earns its place, and even the longer metadata_for sentence is dense with useful, non-redundant detail.

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, the description does not need to explain return shapes. It covers default-oriented behavior, edge cases like unknown folders, search matching, and the special metadata_for mode, making the tool safe and effective 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 is the only source of parameter meaning. It fully compensates by explaining folder with examples and fallback behavior, clarifying search semantics, and defining metadata_for's special 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 description clearly identifies the resource as 'model files installed on the instance' and makes the tool's scope obvious relative to workflow/template siblings. However, it lacks an explicit verb such as 'lists' or 'returns' in the opening sentence, relying partly on the tool name to establish the action.

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 operational guidance: folder selects the model category, search filters filenames, and metadata_for fetches metadata instead. It does not explicitly name alternatives or exclusions among the sibling tools, but the context strongly implies when this read-only model-listing 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint; the description adds valuable behavior beyond those, including catalog size, bundled origin, and how search matches title/description/models. This context is consistent and meaningful.

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?

Three short sentences carry the full needed context: what the tool returns, how to use the result, and how/when to narrow. No filler or redundant restating of the tool name.

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 simple one-parameter read-only tool with an output schema and safety annotations, so the description doesn't need to explain return values. It provides the extra operational context about catalog size and downstream use that makes the tool easy 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?

With 0% schema description coverage, the description compensates completely by explaining that search is a narrowing filter against title, description, and models. Since there is only one optional parameter, this is sufficient for correct use.

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 resource (ComfyUI's bundled workflow templates) and the action (listing a catalog of them), adding scope by noting they ship with every release and are the best starting points. This distinguishes it from siblings like list_workflows because it's specifically bundled templates.

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 concrete usage guidance: narrow with search= and use the result to seed via create_workflow(template=...). It also warns about the catalog size, which implies you should not simply fetch everything. It doesn't spell out when-not-to-use alternatives, but the practical context is 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?

Annotations already cover readOnly, idempotent, and openWorld semantics. The description adds useful context about the data source (userdata) and search behavior, but does not go much deeper; no contradiction with 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?

Three sentences, all relevant. The core resource is front-loaded, the related tool is referenced, and the parameter semantics are stated precisely without 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?

For a simple list-type tool with one optional parameter and an output schema, the description fully covers data source, filtering behavior, and intended next step. Missing return details are not an issue because 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?

The schema provides only a bare string with a default and zero description coverage, but the description explains exactly what the search does: case-insensitive substring filtering of names. That is sufficient for a single optional parameter.

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 clear verb+resource: lists saved Workflow browser workflows from userdata. It also distinguishes itself from import_workflow by indicating these are already-saved items, not arbitrary JSON.

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 connects to import_workflow(name=...) as the follow-up action, giving the agent an immediate workflow chain. It does not spell out when to choose list_workflows over find_workflow or other siblings, so a tiny gap remains.

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 goes well beyond the annotations by explaining the exact destructive scope: clear drops ALL pending prompts, delete drops specific prompt_ids, and interrupt stops the running prompt. It also discloses side effects such as 'free' releasing cached VRAM/RAM and unload_models=True unloading models, plus the ownership guard for prompts queued by other sessions.

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 extremely information efficient, with every phrase adding essential detail. It is front-loaded with the main purpose and action list, then covers safety constraints. No filler or redundant statements appear.

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 complex multi-action behavior, destructive annotations, and 4 parameters, the description is complete: it covers all actions, gating requirements, session ownership semantics, confirmation flow, and memory/model side effects. An output schema exists, so return-value description is 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?

Schema description coverage is 0%, so the description must compensate. It does: the 'action' enum values are all described, 'prompt_ids' context is established via 'delete (drop given pending prompt_ids)', 'confirm' is explained via gating and user agreement, and 'unload_models' is explicitly tied to model unloading. Every parameter receives meaningful semantic explanation.

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: 'Inspect or manage the instance's run queue' and enumerates distinct actions. It is specific about the resource and verb, though it does not explicitly differentiate itself from sibling tools like get_run_status.

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 useful guidance about when actions are allowed, noting that clear/delete/interrupt are 'gated when they'd discard prompts this session didn't queue' and that 'confirm=True' is needed once the user agrees. It does not explicitly mention alternatives or when to choose a sibling tool instead, but the action-by-action breakdown gives clear 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 annotations only declaring readOnly=false/destructive=false/openWorld=false, the description adds substantive context: it MUTATES the session workflow in place, is idempotent, and returns an `applied` summary. The 'replaces a hand-made layout' clause also tells the agent existing layout is overwritten, which is exactly the kind of side-effect detail annotations don't convey. No contradiction with destructiveHint=false, since the mutation is idempotent re-layout, not data loss.

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?

Front-loaded with 'THE finishing step' and the core action, then sequencing, then behavioral caveats — good ordering. It is dense but nearly every clause (idempotent, MUTATES, applied) carries decision-relevant information; the parenthetical about two registers is the one mildly expendable flourish.

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 mutating layout tool with an output schema, the description covers sequencing, mutation semantics, idempotency, and layout-mode meaning, which is what an agent needs to call it correctly. The only gap is the absence of workflow_id semantics, minor given the required-parameter name is self-explanatory.

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 burden: it explains layout='panel' concretely (Controls | Pipeline | Unconnected) and implies 'pipeline' via 'pipeline stage bands'. However, it never explains what layout='pipeline' does differently in terms of grouping, and workflow_id is left entirely undefined. Partial compensation for a fully undocumented 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 names a specific verb and resource ('auto-layout into pipeline stage bands, colored groups, human titles...') rather than restating the name, and explicitly positions itself against siblings: 'Run after wiring, before save_workflow; replaces a hand-made layout.' An agent can distinguish it from edit_workflow, save_workflow, and lint_workflow without opening a schema.

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 a clear sequencing rule ('after wiring, before save_workflow') and states the alternative it supersedes ('replaces a hand-made layout'), which is strong routing guidance. It lacks an explicit when-not/exclusion, but the ordering plus idempotency claim covers most selection needs.

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?

Annotations are minimal but the description goes beyond them by explaining that the tool swaps, rewrites, repicks, and retunes a workflow, and that it returns changes plus flags for human judgment. This gives the agent a realistic picture of the mutation behavior, though it stops short of spelling out every side effect (e.g., whether original workflow files are modified in place).

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/segment pulls its weight: scope, concrete behavior, exclusion, alternatives, and output summary. There is no filler and the crucial 'CROSS-FAMILY ONLY' constraint is 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?

For a tool with two parameters, no schema descriptions, and no enums, the description supplies most of what an agent needs: purpose, scope, help resources, and what the return value indicates. The main missing piece is a precise mapping/example of the two arguments, which the succinct schema alone does not provide, but the overall behavior is well-covered.

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 description coverage is 0%, so the description carries the burden for parameter meaning. It communicates that `target_family` is a model family (via the sdxl->flux example) and `workflow_id` is implicitly the workflow being ported, but it does not explicitly name either parameter or list valid families. It partially compensates but leaves the exact value-space and workflow_id semantics to the agent.

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 very specific scope, 'CROSS-FAMILY MODEL PORT ONLY', and gives a concrete example ('sdxl' -> 'flux'). It then enumerates exactly what the tool does: swaps loader topology, retunes CFG/steps/sampler/scheduler, swaps latent node class, and picks model files. This clearly distinguishes it from generic editing or diagnostic 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 explicitly states when NOT to use it ('NOT for fixing missing/uninstalled nodes') and names the exact alternative tools to use instead ('diagnose_workflow + resolve_missing_nodes'). It also points to supporting tools for family knowledge ('get_model_guidance / get_instance_info'), leaving minimal inference for the agent.

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?

Annotations already disclose this is a non-readOnly, non-destructive, closed-world write. The description adds real behavioral context beyond that: it is the only path by which a URL appears in organize_workflow's note ('it never invents a URL'), and it warns to verify the URL resolves. It still doesn't describe storage scope or persistence lifetime, but the added context is substantial.

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?

Content is front-loaded with purpose first, and the examples earn their space, but the prose is dense with awkward line breaks and multiple nested JSON snippets that could be tightened. It borders on longer than necessary for three parameters.

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?

An output schema exists so return values need no explanation, and all three parameters are meaningfully described despite zero schema coverage. The detect-block and sources-list mechanics make the write operation actionable; only storage/persistence semantics remain lightly specified.

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 carry the burden, and it largely does: 'updates' is explained with concrete guidance-shape examples, 'source' is defined as URL/model page, and 'family' semantics plus the optional 'detect' block are spelled out. Only minor details (e.g., allowed loader values, matching semantics) are left implicit.

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 specific verb and effect: persist researched settings so future sessions start smarter, which is distinct from read-only siblings like get_model_guidance. It does not explicitly contrast itself with those siblings, but it references organize_workflow's Models note, giving some relational clarity.

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?

Usage is implied through conditional guidance ('for a NEW family also include a detect block') and a caveat about URL verification, but there is no explicit when-to-use vs when-not-to-use statement or named alternative. An agent can infer the post-research context but must reason it out.

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?

Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, so the description is free to add context. It does so by specifying that the tool returns pack ids, repos, and install hints, and by flagging the third-party code risk associated with installing custom nodes. This adds meaningful behavioral context without contradicting the 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 tight and purposeful: a clear first sentence names the tool's function, the second distinguishes it from a sibling, and the third adds output and risk context. Every sentence earns its place without padding.

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 tool with an output schema and three annotations, the description covers purpose, selection criteria, return values, and the important user-consent caveat. There is no major contextual gap for an agent to successfully select and invoke 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 description coverage is 0%, so the description must compensate. It usefully clarifies the parameter as node class names, but it does not fully explain the expected format or source of those class names beyond their obvious semantic connection to missing nodes.

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 action and resource: find which installable node packs provide the queried node class names, scoped to the official Comfy Registry. It also explicitly states this is the tool for missing/uninstalled nodes and names a sibling tool it is not, making differentiation clear.

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 an explicit boundary: use this for missing/uninstalled nodes, while port_workflow is for model-family moves and not for missing nodes. It also gives operational guidance by warning that installing custom nodes runs third-party code, so the user's choice must be surfaced.

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 discloses behavior well beyond the sparse annotations: timeout only cancels the wait, not the job; queue_busy is returned when prompts are pending; save relocation requires wait=True or later save_output; and spend-gated partner/API nodes require explicit confirmation.

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 and dense with useful information, appropriate for a complex 10-parameter tool. It could be more structured, but almost every sentence carries operational value rather than restating schema 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?

With no output schema and sparse annotations, the description compensates by documenting return shapes, failure behavior, preview behavior, sweep results, and long-render workflow. An agent has enough context to invoke the tool correctly without opening another source.

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 with 0% schema description coverage across 10 parameters, the description explains the practical meaning of the non-obvious ones: wait, front, sweep, save_dir, roll_seeds, allow_invalid, confirm_spend, return_preview, and timeout behavior. workflow_id is only implicitly defined, but the overall parameter coverage is far above baseline.

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 specific verb and resource: queue a workflow and optionally wait for completion. It immediately clarifies the returned data and distinguishes the polling path by naming get_run_status when wait=False.

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 operational guidance: use wait=False plus get_run_status for long renders, use save_output afterward, and prove a workflow works before saving. It also explains when front=None should be used and when confirm_spend=True 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, and the description adds genuinely useful context: the output/ write restriction on save nodes, the COMFYUI_MOUNT_DIR default for dest_dir, and the returned shape. It omits the behavior of the `overwrite` flag, which is the one remaining mutation-risk question.

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?

Front-loaded with the core action and the reason, then the two invocation modes, then the return shape — no filler sentences. Slightly dense with parentheticals, but every clause carries 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?

An output schema exists so return values needn't be spelled out, yet the description still summarizes {saved_paths, dest_dir}. For a 7-parameter write tool with 0% schema coverage, the only meaningful gap is the overwrite behavior and any permission/auth requirement.

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 does most of it: prompt_id semantics (relocates every output file), filename with subfolder/type, dest_dir defaulting to COMFYUI_MOUNT_DIR, and dest_filename as a single-file rename. Only `overwrite` is left unexplained.

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 ('Copy a finished render out of ComfyUI's output tree into a folder the caller can reach') and immediately scopes it against the alternative mechanism ('save nodes only write inside output/'). This clearly separates it from read-only siblings like view_output.

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 gives the two invocation modes — pass prompt_id to relocate every output file of a finished job, or an explicit filename plus subfolder/type. It explains why the tool is needed (sandbox reachability) rather than naming a competing sibling tool, so it is clear context without explicit 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?

Annotations only say readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description goes well beyond: it refuses to save on validation errors unless allow_invalid=True, never overwrites by default (renaming to '<name> (draftsman)' and reporting result.renamed_from), and overwrite=True replaces deliberately. That is exactly the mutation-safety context annotations cannot 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?

Front-loaded with the core action and destination, then escalates to the behavioral rules. Dense but each clause carries information; the parentheticals are informative rather than 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?

Covers the save target, the validation refusal, and the rename/overwrite policy, and an output schema exists so return values need no explanation. The identifier semantics of workflow_id and name are the remaining gap for a 4-parameter mutation 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 coverage is 0%, so the description carries the burden. It richly explains overwrite and allow_invalid semantics, but says nothing about what workflow_id or name refer to (an ID from create_workflow? a display name?). Two of four parameters remain undocumented, so it only partially compensates.

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 ('Save the workflow') plus the exact artifact written ('UI format, with layout/groups/notes') and both destinations (workflow browser + session dir). This distinguishes it from export_workflow_json and save_output without opening either schema.

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 a clear precondition: 'Organize a graph you built first (not a hand-arranged one)', which routes the agent to organize_workflow before saving. It does not name organize_workflow explicitly or contrast against export_workflow_json, so it falls 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?

Annotations already report readOnly, openWorld, and idempotent, and the description's 'search' wording is consistent. It adds the domain context of the Comfy Registry, but it does not disclose extra behavioral details such as rate limits, result size, pagination, or permissions.

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 sentence that explains the operation, resource, scope, and examples real.true. There is no filler, repetition, or redundant restatement of the 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?

This compact one-parameter, read-only, idempotent search tool with an output schema needs only modest explanation. The description succeeds exception it could not mention whether the query accepts natural language, exact terms, or a specific search syntax.

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 says 'query' is a string, so the description must compensate for the bare schema. It tells the agent that the query should be a capability and gives meaningful examples ('face detailer', 'wildcards', 'video interpolation'), making the parameter's intended semantics clear despite no extra schema help.

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 an operation ('search'), a resource ('Comfy Registry node packs'), and the search facet ('by capability') with concrete examples. This distinguishes it from sibling search_nodes because it targets node packs rather than nodes or other resources.

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 capability examples imply when the tool should be used, but the description never explains when to prefer it over search_nodes or another sibling. There is no explicit exclusion, alternative routing, or contextual condition beyond the phrase 'by capability.'

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?

Annotations already cover read-only/idempotent/open world aspects. The description adds useful behavioral context: what fields are searched, how category narrows results, and that detail=True folds full I/O schema into each hit, letting the agent avoid a second call. No contradictions with the read-only/idempotent hints.

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 compact sentences front-load the core purpose and then give targeted usage and efficiency tips. Every clause adds value, no redundancy or filler. The structure is easy to parse for an agent: search, narrow, get details as needed.

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 this read-only search tool given the output schema and annotations. It tells the agent what it searches, how to narrow with category, when to request detail, and how to avoid a follow-up get_node_info. Nothing essential for selecting or invoking this tool 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?

Schema description coverage is 0%, so the description carries the burden. It explains query semantics (search over name/display-name/description), category (narrow with examples), detail (in-line schema), and limit (small limit when using detail). It doesn't describe the bare 'limit' term, but that is semantically evident from the schema default.

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: 'Search node classes installed on the instance' with explicit match fields (name/display-name/description). It distinguishes itself from sibling tools by noting that setting detail=True lets you 'skip the follow-up get_node_info', and the word 'classes' separates it from search_node_packs.

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 actionable guidance with concrete category examples ('loaders', 'conditioning', 'sampling', 'ImpactPack') and a rule for detail usage: set detail=True with a specific query and small limit to skip get_node_info. It clearly explains how to adjust behavior, though it doesn't enumerate when *not* to use this tool versus all possible siblings.

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?

Adds meaningful behavioral context beyond the sparse annotations: the uploaded file lands in the input folder, exactly one of image_path or image_base64 must be supplied, and mask_for changes the behavior to upload as a MASK instead of an image. It does not cover the effect of the overwrite parameter, which could be a destructive operation, nor the filename derivation semantics; this is a minor gap given the destructiveHint annotation.

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 with zero filler; the core purpose is front-loaded and the second sentence captures the two critical behavior twists (exclusivity and mask mode). Every sentence earns its place and does not repeat schema contents.

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 real complexity (6 params, 0% schema coverage, limited annotations), the description covers the highest-risk information: the destination, the input modes, and the mask variant. An output schema exists so the return value is already covered, but the description still omits overwrite and subfolder edge behavior, which an agent may need for correct usage.

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?

With 0% schema description coverage, the description carries the full burden and largely delivers: it explains image_path (local file) vs image_base64, their mutual exclusivity, and decomposes mask_for's shape with its subfields. It is silent on name, subfolder, and overwrite, whose semantics are inferable from their names and defaults, so the compensation is solid but not exhaustive.

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: uploads a source image into ComfyUI's input folder so LoadImage can use it, and names the use cases (img2img / inpaint / ControlNet). This clearly distinguishes it from the sibling tools, especially save_output which moves data out rather than into the ComfyUI input folder.

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 context for when to use this tool: before workflows that need LoadImage to reference an input image for img2img, inpaint, or ControlNet. It documents the exclusive either/or of image_path vs image_base64 and the mask_for alternative mode. It does not explicitly state when not to use it or name a sibling as an alternative, so no exclusion is given.

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?

It clearly communicates that validation happens against the live instance and includes detailed behaviors such as 'closest-match suggestions'. This adds practical nuance beyond the readOnlyHint/idempotentHint annotations. No contradictory behavior is implied.

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 and front-loaded with the main purpose. Every clause adds meaningful detail, though the closing instruction 'Fix errors before run_workflow' is a behavioral guideline rather than a descriptive detail.

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?

It covers the key validation dimensions and current environment scope, and the output schema handles structured return information. The only minor gap is the absence of explicit mention whether validation fully blocks execution or merely warns.

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 only one parameter, workflow_id, but the description never explicitly explains this parameter beyond the inferred meaning of 'validate the workflow'. With schema description coverage at 0%, the description should compensate, and it does not add direct parameter-level 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 starts with a specific action and target: 'Validate against the LIVE instance'. It enumerates concrete validation checks (node classes installed, widget values, combo/model-file values, required inputs connected), which clearly separates this from static analysis tools like lint_workflow or diagnose_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 phrase 'Fix errors before run_workflow' makes the intended context explicit: this is a pre-flight validation step before execution. It does not name alternatives or state when not to use this tool, so it stops short of the strongest form of usage 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?

Annotations already cover read-only, open-world, and idempotent behavior, so the safety profile is clear. The description adds meaningful behavioral context beyond the annotations by disclosing downscaling to max_dim and the full-resolution behavior when max_dim is None. It is honest about what it fetches and why the scaling behavior 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 compact and front-loaded: it says what the tool is in the first clause and the why behind the behavior in the same breath. Every sentence earns its place, with no repeated information 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?

For a 4-parameter tool with no output schema, the description is a bit thin: It leaves filename semantics and the meaning of type/subfolder implicit, and it does not mention how the fetched image is returned to the agent. The source-of-truth pointer to run_workflow/get_run_status outputs helps, but more documentation would improve usability.

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 responsibility for explaining parameters. It only explains max_dim and its resolution behavior. filename, type, and subfolder are left undocumented, and the description does not state how these map to the output refs received from run_workflow/get_run_status. This is a meaningful gap for an agent trying to invoke the tool 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 clearly identifies the action ('Fetch a rendered image') and why it is used ('so you and the user can SEE it'). It also anchors the image source to run_workflow/get_run_status outputs, which helps differentiate this viewer from the workflow-management siblings. It does not explicitly name or distinguish a sibling tool, so it stops just short of a 5.

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 the intended use: fetch an image after running a workflow and looking at run status output. It does not explicitly state when not to use this tool or mention alternatives such as save_output, upload_image, or get_run_status. Some usage context is present, but it is largely implicit.

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