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?

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false) by disclosing batch semantics: ops apply in order, a failing op halts the batch with the graph unchanged past that point, and validation (widget values, link types) is checked live with 'force': true as an override. It notably does not call out that remove_node/remove_group are destructive, which the destructiveHint=false annotation does not surface either.

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?

Long but dense and front-loaded with the core action before the op reference; each bullet earns its place as an executable op signature. It is on the verbose side for a description, but little could be cut without losing invocation-critical 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?

For a complex, high-arity mutation tool with an output schema, the description covers the op grammar, ordering/failure behavior, validation and force semantics, virtual-class edge cases, and where slot names come from (get_node_info). An agent has everything needed to build a correct batch without opening the 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 full burden and does so thoroughly: every op shape, its required keys, and which keys are optional is spelled out (e.g. add_node's class_type/ref/widgets, replace_in_widget's single-match 'old', set_mode's 0/2/4 codes). This is far more than the bare schema provides.

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

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

Opens with a specific verb+resource ('Apply batched edits') and then enumerates the exact operation vocabulary (add_node, connect, set_widget, etc.), so an agent knows precisely what capability this exposes. It also distinguishes itself from siblings by naming the definition-scoped twins and organize_workflow/inspect_workflow as related 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?

Gives real sequencing guidance: layout/group ops should run after organize_workflow, and inspect_workflow/summary=true is offered when the compact delta is insufficient. It stops short of stating when NOT to use edit_workflow versus save_workflow or create_workflow, so it's clear context without explicit exclusions.

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

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

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?

The description goes well beyond the annotations by explicitly stating that the tool MUTATES the session workflow in place and is idempotent. It also explains what the result contains (the applied block) and how to see the full reorganized graph, which is valuable context that the annotations do not provide.

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

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

The description is compact but information-dense: two sentences carry purpose, sequencing, mutation semantics, idempotence, and output behavior. The key instruction is front-loaded and every sentence earns its place.

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

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

The description covers the main operational requirements: when to call it, what it mutates, idempotence, what the result contains, and how to inspect the complete output. Since an output schema exists, the description does not need to restate return values, and it gives the agent enough context to invoke the tool correctly.

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

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

The schema coverage for workflow_id is 0%, and the description does not explain workflow_id explicitly. However, the repeated mention of 'session workflow' and 'workflow' implies that this ID selects the target workflow to be organized. For a single, self-describing identifier parameter, this is adequate but not fully explicit compensation.

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 clear verb and resource: it auto-layouts the workflow into pipeline stage bands, colored groups, human titles, highlights, and guidance notes. It also distinguishes itself from sibling tools by being explicitly 'the finishing step' before save_workflow, rather than an inspection, validation, or save operation.

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

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

It gives clear lifecycle guidance: run after wiring and before save_workflow. It also tells the agent that inspect_workflow or export_workflow_json can be used afterward to view the full result. It does not explicitly name alternatives for when not to use it, so it falls just short of a perfect dimension.

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?

With annotations present (readOnlyHint=false, destructiveHint=false), the bar is lower, and the description adds real behavioral context: persistence affects future sessions, a 'detect' block enables auto-recognition next session, and the tool 'never invents a URL, so this is the only way one appears' — a genuine policy disclosure. It also instructs URL verification before recording. Nothing contradicts the annotations: readOnlyHint=false is consistent with a persist operation.

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

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

The description is somewhat long, but every segment earns space: the purpose is front-loaded, the updates shape needs its examples, and the NEW-family and sources-list paragraphs cover mandatory edge cases. It is densely structured with little fluff, though the many inline JSON examples make it verbose by necessity.

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?

All three required parameters are explained, edge cases (new family detection, sources-only URL introduction) are covered, and an output schema exists, so return values need no explanation. The remaining gaps are minor: it presupposes familiarity with 'the guidance shape', and it does not describe what happens on failure or how recorded settings interact with get_model_guidance. For a high-complexity tool the description is still complete enough for a first-call agent.

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

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

Schema coverage is 0%, so the description carries the full burden and fully compensates: it assigns meaning to 'family' (any family name, with the NEW-family detect/loader variant), 'source' (URL/model page) and 'updates', with concrete shape examples such as {"sampling": {"cfg": {"default": 3.5}}}. It also explains the separate 'sources' list block and how the pattern matches checkpoint filenames. This is exemplary parameter documentation for a bare schema.

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

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

The description opens with a precise verb+resource: 'Persist researched settings so FUTURE sessions start smarter.' This clearly expresses a write/update operation over a learning/guidance resource, which is readily distinguishable from the retrieval-oriented sibling get_model_guidance and from organize_workflow. The intent is unambiguous even without reading 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?

The description is rich with intra-tool guidance: when updating provide the guidance shape, for a NEW family include a detect block, and include a sources list only to introduce URLs. However, it does not explicitly say when to use this tool vs. the alternatives (e.g., get_model_guidance for the read side of the same data), nor does it state any exclusions or conditions that would route an agent elsewhere.

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?

Annotations only say non-read-only, non-destructive, open-world; the description adds substantial context beyond that: spend gating on partner/API nodes, the {status: queue_busy} refusal behavior, the fact that a timeout cancels the wait but not the job, seed re-rolling persistence, and output relocation requiring wait=True. This is exactly the extra behavioral layer the annotations cannot carry.

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 contract, then organized by parameter/topic; nearly every sentence earns its place. It is dense and telegraphic, and the sweep and LONG RENDERS blocks are slightly hard to parse on first read, but there is little genuine waste.

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

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

For a 10-parameter tool with no output schema and no annotation detail, the description covers return shapes, failure modes, queueing, spend, and long-run recovery. An agent has everything needed to invoke and recover from it correctly.

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

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

Schema description coverage is 0%, so the description must carry the full burden, and it does: it explains wait, front (three-valued semantics with the queue_busy case), sweep (its variant/seed/crop sub-structure and limits), save_dir, roll_seeds, allow_invalid, confirm_spend, return_preview, and timeout behavior. Only workflow_id is left implicit, which is reasonable.

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 ('Queue the workflow and (by default) wait for completion') and immediately enumerates what comes back (status, node errors, file refs, data_outputs, preview thumbnail). It is clearly distinguishable from siblings like get_run_status, save_output, and manage_queue, which it names as downstream steps.

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 guidance throughout: wait=False when you want to poll, return_preview=False for text-only callers, allow_invalid for bypassing local validation, confirm_spend only after the partner agrees, and a full 'LONG RENDERS' recipe naming get_run_status and save_output. It also routes the user-choice case via front=None.

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?

The description discloses several non-obvious behaviors beyond the annotations: it refuses invalid saves unless allow_invalid=True, never overwrites by default, renames collisions to '<name> (dartsman)', reports this through result.renamed_from, and replaces only when overwrite=True. The annotation destructiveHint=false is compatible with the default non-destructive path; overwrite is an explicit opt-in rather than an annotation 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?

The description is dense but every clause adds information: purpose/format, prerequisite/mission, validation behavior, collision behavior, and overwrite semantics. There is no filler or repetition of schema/annotation fields, and the most important purpose 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 4-parameter tool with an output schema, the description covers the key invocation constraints: prerequisite, validation gating, overwrite risk, and collision naming. The main gap is that workflow_id and name are not explained in the description, so the agent must rely on parameter names and schema type information.

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

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

Schema descriptions cover 0% of the parameters, so the description must compensate. It does explain the behavior of allow_invalid and overwrite, and the naming behavior around name collisions, but it never explicitly explains workflow_id or that name is the new save name. These are inferable, but the description leaves part of the parameter-load 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 clearly identifies the action ('Save the workflow'), the resource ('UI format, with layout/groups/notes'), and the destination ('ComfyUI's workflow browser + session dir'). It does not explicitly name a sibling it is not, but the UI-format qualifier and the mention of session-dir saving distinguish it from export-only or output-saving tools.

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

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

It gives a concrete precondition ('Run organize_workflow first'), explicitly says this is the deliverable, and explains when validation errors block saving unless allow_invalid=True. It does not explicitly contrast itself with sibling tools such as export_workflow_json or save_output, so the routing guidance is clear but not comprehensive.

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.