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

No annotations exist, so the description carries the burden; it does usefully disclose the return value (new node id as a string), which compensates for the missing output schema. However, it says nothing about persistence, whether the node is initially unconnected, or error behavior for an invalid class_type/workflow_id.

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 sentences, action first and return value second, with zero waste. Ideal for a simple mutation tool.

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 a simple 3-parameter tool with complete schema coverage and a described return value, the definition is largely sufficient. Only the workflow-sequencing and persistence semantics are absent, which are minor for this tool.

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

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

Schema description coverage is 100%, so required workflow_id, class_type, and inputs are already documented with examples, including the note to use connect_nodes for links. The description adds nothing beyond the schema for parameters, which is the baseline 3 case.

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 ("Add a node") and scope ("to a dynamic workflow"), and even discloses the return value. It is distinguishable from remove_node/connect_nodes, but it does not explicitly name those siblings as alternatives.

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

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

No guidance on when to use this versus connect_nodes, set_node_input, or build_workflow, and no stated prerequisite that a workflow must first be created via create_workflow (that only appears in the schema). The agent must infer the workflow-building sequence.

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

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

With no annotations, the description carries the burden; it does disclose the return value (executable workflow JSON). However, it omits error behavior — what happens on missing/extra parameter keys, whether values are validated, or whether the template is checked for structural validity. Sibling validate_template_params hints these concerns exist and go unaddressed.

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, front-loaded with the action and the return value, then the upstream tool reference. 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?

For a two-parameter tool with a fully described schema and no output schema, the description covers purpose, output shape, and upstream dependency. The main missing piece is failure-mode guidance (invalid values vs. invalid template), which would fully close the gap.

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 100%, so both parameters are documented in the schema, making 3 the baseline. The description adds only a conceptual framing of 'parameter values' and a provenance note that the template string comes from create_template, without extra syntax or format detail.

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

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

States a specific verb and resource ('Apply parameter values to a workflow template') and immediately describes the output ('workflow JSON ready to execute or save'). It also contrasts with the sibling create_template, so an agent can distinguish the two without opening schemas.

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 workflow: use create_template to build a template, then apply_template with values. That establishes context and ordering. It does not mention when-not-to-use (e.g., when params are unvalidated, validate_template_params might be a prerequisite), so it falls short of a 5.

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

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

With no annotations, the description carries the full burden. It does disclose useful behavior: it builds rather than executes, returns workflow JSON plus a recipe for regeneration, and restates denoise semantics. However, it doesn't say whether the workflow is saved, how it relates to execute_workflow, or what happens on invalid input - gaps for an unannotated tool with 10 parameters.

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 tightly packed sentences with zero waste; the core capability and return value are front-loaded, and the prerequisite and style options follow logically. Slightly dense but appropriately sized for the tool's complexity.

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

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

No output schema exists, and the description does explain the returned workflow JSON and recipe, plus the input-folder prerequisite. But for a 10-parameter, no-annotation tool it leaves generation parameters (cfg, seed, steps, negative_prompt, ckpt_name) unaddressed and doesn't clarify the build-then-execute handoff to execute_workflow.

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 70%, so the schema already documents image, style, prompt override, denoise, ckpt_name, filename_prefix, and negative_prompt. The description mostly repeats the style keyword list already present in the schema and says nothing about cfg, seed, or steps, so it adds little beyond structured fields - baseline 3.

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: builds a workflow that takes an image and outputs a restyled image, and explicitly names what it returns (workflow JSON plus a prompt/params recipe). It is distinguishable from the generic build_workflow sibling by being style-transfer specific, though it never names that sibling to make the contrast explicit.

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

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

Gives a clear precondition ("Image must be in ComfyUI input folder (upload first if needed)") that tells the agent what must happen before calling. It also explains the style-vs-free-text usage, but offers no explicit when-to-use/when-not guidance against sibling builders like build_workflow or create_template.

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

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

With no annotations, the description carries the full burden. It discloses the return value ('workflow JSON ready to execute or save') and a hardware prerequisite for FLUX, which is useful. It does not state whether the workflow is persisted, what permissions are required, or what happens on invalid templates/params, leaving meaningful behavioral gaps.

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 compact sentences with no wasted text. Purpose and return value are front-loaded, and the conditional FLUX guidance follows directly. 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 purpose, output, and an important precondition for one template. The input schema fully documents the two parameters and enumerates expected param keys. It is slightly incomplete because it does not clarify relationships to nearby workflow-building tools.

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 100%, so both parameters are already documented in structured fields. The description does not add syntax, defaults, or validation details beyond the schema. A baseline 3 is appropriate because the schema already does the parameter-documentation work.

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: 'Build a ComfyUI workflow from a template and parameters.' It also says what the output is: workflow JSON ready to execute or save. It does not explicitly distinguish itself from siblings such as create_workflow, apply_template, or build_restyle_workflow, so it falls 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?

Provides an explicit conditional path for txt2img_flux: call get_system_resources first and use only when flux_ready is true. This is clear usage guidance for one template, including a when-not condition. However, it gives no guidance on choosing between this tool and related workflow-building siblings like create_workflow or apply_template.

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

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

With no annotations, the description carries the full burden. The wording 'Check if' strongly implies a read-only lookup against node-compatibility.json, but it does not describe the return value, possible error cases, or whether any side effects occur.

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

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

The description is a single compact sentence that states the operation and the compatibility source. There is no wasted text, and the core 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?

The tool is simple and the schema is fully documented, but there is no output schema and the description does not explain what the check returns or how failures are represented. That leaves a meaningful gap for an agent invoking 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?

Schema description coverage is 100%, so both parameters are already documented as source and target node class names. The description adds a little directionality by saying 'output of one node' to 'input of another,' but it does not expand parameter semantics beyond the schema.

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

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

The description gives a specific verb and resource: check whether one node's output can connect to another node's input. It is clear enough to distinguish from sibling tools like connect_nodes, though it does not explicitly name those alternatives.

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

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

Usage is implied: use this before making a connection to see if it is valid. However, the description does not explicitly say when to use it instead of connect_nodes, validate_workflow, or get_node_inputs/get_node_outputs.

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

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

With no annotations, the description carries the full burden; it does disclose that the check is performed against object_info model lists (useful behavioral detail) and that COMFYUI_HOST must be configured. It does not state the return shape (presumably boolean), failure behavior, or whether the server is queried live each call.

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 sentences, zero waste, with the core purpose front-loaded and the environment prerequisite trailing usefully.

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 two-parameter existence check with fully documented schema, this is nearly complete; the only gap is the unstated return value, which is not covered by an 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 100%, with both 'name' and an enumerated 'type' documented in the schema, so the baseline is 3. The description adds no extra semantics about filename format or type matching.

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 ('Check') and resource ('if a model exists on the ComfyUI server'), and clarifies the backing data source ('object_info model lists'), which distinguishes it from list_models/get_model_info. It does not explicitly name those siblings as alternatives, so it falls 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?

'Requires COMFYUI_HOST' gives a prerequisite, and the name plus description imply a pre-flight existence check, but there is no explicit when-to-use vs. list_models, get_model_info, or check_compatibility 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?

No annotations are provided, so the description carries the full burden. It discloses useful behavior: it checks the ComfyUI server, returns ready/missing/found lists, and requires COMFYUI_HOST. It does not state whether the check is read-only, how the server is contacted, or whether the workflow itself is validated.

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

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

The description is three tightly written sentences with the purpose front-loaded, followed by return values and an environment prerequisite. Every sentence contributes useful information without repetition.

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

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

For a one-parameter check with no output schema or annotations, the description is largely complete: it covers purpose, environment prerequisite, and the main return fields. It could be more explicit about the format of missing/found lists and when to use it versus similar tools.

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 single workflow parameter is fully documented by the schema as 'Workflow JSON string', so the schema does the heavy lifting. The description adds no additional syntax or format details beyond implying that the workflow determines the required models.

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: check which models required by a workflow exist on the ComfyUI server. It is clear what the tool does, but it does not explicitly differentiate itself from similar siblings such as get_workflow_models or check_model_exists.

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

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

Usage is implied by the phrase 'required by a workflow' and the availability check, suggesting it is used before executing a workflow. However, there is no explicit guidance on when to prefer this over siblings like get_workflow_models, check_model_exists, or validate_workflow.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the destructive scope ('remove all pending and stop/clear running') and the COMFYUI_HOST requirement, but omits whether running work is irrecoverably lost, permission needs, and whether any confirmation/return is given.

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 front-loaded sentence stating the action, its effect, and the env requirement with zero 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 no-param, no-output-schema tool the description covers action, scope, and a configuration prerequisite. It is nearly complete; only the loss/irreversibility semantics would add useful context.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the empty schema is self-explanatory and the baseline applies.

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

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

States a specific verb ('clear') and resource ('ComfyUI queue') plus the exact effect: 'remove all pending and stop/clear running.' The 'all' scope implicitly separates it from delete_queue_items, though no sibling is named explicitly.

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

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

Usage is implied by the effect description (wholesale purge vs. selective deletion), but it never states when to prefer this over delete_queue_items or interrupt_execution, nor any prerequisite beyond the host variable.

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

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

No annotations are provided, so the description carries the full burden, yet it discloses nothing about mutation semantics: whether an existing connection on the target input is replaced, whether types are validated (a separate check_compatibility tool hints they might not be), or what happens on an invalid node id or out-of-range output_idx.

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 front-loaded sentence that names the action and both endpoints with no filler. It is efficient but under-specified rather than maximally informative for a 5-required-param mutation tool.

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 write operation with no annotations, no output schema, and five required parameters, the description omits the essentials an agent needs: lifecycle ordering (create_workflow → add_node → connect_nodes → validate_workflow), overwrite behavior, and error conditions. The rich schema helps with parameter mechanics but not with correct invocation context.

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

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

Schema description coverage is 100%, so all five parameters are already documented with examples (from_node e.g. "1", output_idx usually 0, input_name e.g. model/clip/positive). The description only restates the from/output-to/input mapping and adds no format or constraint detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (connect) and resource (an output of one node to an input of another) scoped to a dynamic workflow. An agent can tell it apart from add_node/remove_node, but there is no explicit differentiation from set_node_input, the nearest sibling for wiring values.

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

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

No guidance on when to use this versus set_node_input or check_compatibility, and no prerequisites such as the workflow already existing (created via create_workflow) or both nodes already being added. The agent must infer the ordering from sibling names alone.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns template JSON and that parameters bind to node inputs via nodeBindings, but it does not clarify persistence, permissions, validation behavior, or what happens on failure.

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

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

The description is three focused sentences with no wasted text. It front-loads the core action, then covers output usage and binding semantics.

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?

There is no output schema, but the description states that the tool returns template JSON and names the downstream tools that consume it. It could say more about persistence or output shape, but it is mostly complete for this creation tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining that params bind to node inputs through nodeBindings (nodeId, inputName), clarifying a relationship not fully explained by the schema alone.

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 specific verb and resource: 'Create a parameterized workflow template from a workflow and parameter definitions.' It clearly distinguishes creation from sibling operations such as apply_template, validate_template_params, and list_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 says the returned template JSON is for use with apply_template or validate_template_params, which gives clear downstream context. It does not explicitly compare against create_workflow or explain when not to create a template, but the use case is well implied.

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

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

With no annotations, the description must carry the full behavioral burden. It discloses the return value and the downstream usage chain, but it does not explain whether the empty workflow context is persisted, whether cleanup is required, or what side effects occur on the server.

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, both front-loaded and free of waste. The first states what the tool does; the second states the return value and immediately useful downstream tools.

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

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

For a zero-parameter initialization tool without an output schema or annotations, the description is nearly complete: it states the creation of an empty context, the returned workflow_id, and the follow-up tools. It could say more about persistence or lifecycle, but the essentials for correct invocation are present.

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

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

The tool has zero parameters, so there is no parameter semantics to document. The baseline for a zero-parameter tool is 4, and the description appropriately does not invent parameter details.

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

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

The description uses a specific verb and resource: 'Create a new empty workflow context.' It distinguishes this initialization step from the many sibling workflow tools by stating it returns a workflow_id for use with add_node, connect_nodes, get_workflow_json, validate_workflow, finalize_workflow, and execute_workflow.

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

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

The description clearly situates the tool as the first step in a workflow-building sequence by naming the downstream tools that consume its returned workflow_id. It does not explicitly compare create_workflow with build_workflow or build_restyle_workflow, but the initialization framing makes its intended role 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?

No annotations are provided, so the description carries the full behavioral burden for a mutation tool. It mentions the COMFYUI_HOST requirement but does not disclose whether removal affects running versus pending items, whether it is reversible, or what happens on invalid prompt_ids.

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, front-loaded with the action and followed by the lookup dependency and config prerequisite. No wasted text.

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

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

Adequate for a one-parameter tool with full schema coverage and no output schema, but as an unannotated destructive operation it should disclose more about queue state and side effects.

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 100%, so the single prompt_ids parameter is already documented in the schema. The description reiterates that IDs come from list_queue but adds no format or validation detail beyond the schema.

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

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

Names a specific verb and resource ('Remove specific items from ComfyUI queue') and scopes it by 'prompt_id', which clearly distinguishes it from broad queue operations like clear_queue.

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

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

Gives a concrete prerequisite step: use list_queue to get prompt_ids. It does not explicitly contrast with clear_queue or interrupt_execution, so the agent must infer when removal is preferable to clearing or interrupting.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that this is a live GET request against a running instance, identifies the endpoint, and states the returned content (class names and categories). The GET verb implies read-only behavior, and the running-instance requirement covers a key operational constraint, though failure modes and output shape details are not fully elaborated.

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

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

The description is three compact sentences that front-load the core action, then the endpoint, then the return content and requirement. Every sentence adds useful information without repetition 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 zero-parameter, live-read tool with no annotations or output schema, the description covers the key operational facts: it reads from a running instance, names the endpoint, and describes the returned data. It is nearly complete, though it could better distinguish itself from related node-listing tools and more precisely describe the output structure for an agent needing to interpret results.

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

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

The tool takes zero parameters and the input schema is empty with 100% coverage, so there is no parameter semantics to document. The baseline for zero parameters is 4, and the description appropriately does not invent parameter details.

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

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

The description names a specific verb and resource: 'Get all node definitions from the running ComfyUI instance' and even identifies the endpoint GET /object_info. It states what is returned (class names and categories), making the tool's function clear. However, it does not explicitly distinguish this tool from siblings like list_node_types, list_node_categories, or get_node_info.

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 a prerequisite: 'Requires ComfyUI to be running at COMFYUI_HOST,' which is useful context. But it gives no explicit guidance on when to use this tool versus alternatives such as list_node_types, sync_nodes_to_knowledge, or search_nodes. Usage is only implied by the live-instance requirement.

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

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

No annotations are provided, so the description carries the burden. It usefully discloses the COMFYUI_HOST prerequisite and that it returns a list of saved paths, but says nothing about overwrite behavior when files already exist, failure modes, or whether the directory must pre-exist.

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

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

Three short sentences, front-loaded with the action and resource, with zero filler. Slightly terse but every sentence contributes something.

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 3-parameter download tool with no annotations and no output schema, the description covers the return value and the env prerequisite, but omits practical concerns like directory creation, collision handling beyond the prefix flag, and error conditions.

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 100%, so all three parameters including prefix_node_id are documented in the schema. The description adds no semantics beyond what the schema already states, which is the expected baseline.

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

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

States a specific verb+resource: downloading all output files for a prompt into a directory, plus the return value. The word 'all' implicitly distinguishes it from the single-file siblings download_output and download_by_filename, though it does not name them explicitly.

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

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

Usage is only implied by 'all output files' – an agent can infer this is the bulk variant versus the single-file downloaders, but there is no explicit when/when-not guidance or named alternative.

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

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

With no annotations, the description carries the full burden and does well: it discloses that return_base64 skips disk writes, that files over 800 KB are auto-converted to WebP to fit base64 limits, and that COMFYUI_HOST is required. It stops short of stating overwrite behavior on dest_path or what happens on a missing filename.

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 purpose and the no-prompt_id qualifier, then behavior, then the environment prerequisite. Five sentences, nearly all substantive; 'Uses GET /view' is the only line that leans toward implementation trivia rather than agent-relevant guidance.

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 an 8-parameter tool with no annotations and no output schema, the description supplies the behavioral payload an agent needs: where the filename comes from, the base64-vs-disk branch, size-triggered conversion, and the host requirement. Only the return shape for the non-base64 (file-written) path is 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 coverage is 100%, so baseline is 3, but the description adds genuine meaning the schema does not: return_base64 suppresses disk writes entirely, and the 800 KB auto-WebP threshold explains the default for max_base64_bytes. These are interaction semantics rather than restated field labels.

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?

Specific verb+resource: 'Download an output file by filename' with the explicit disambiguator '(no prompt_id needed)' and the underlying endpoint. This cleanly separates it from download_output (prompt_id-based) and download_all_outputs in the sibling list.

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?

'Use when you have filename from get_history or get_last_output' gives a concrete triggering condition and names the upstream tools that produce the input. It does not state the inverse case (use download_output when you have a prompt_id), so the alternative is only implied.

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

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

With no annotations, the description must carry behavioral burden; it does add useful environment context ('Requires COMFYUI_HOST') and discloses the format-conversion side effect. It is silent on key write behavior: whether an existing file at dest_path is overwritten, whether missing directories are created, and what happens on failure — significant gaps for a tool that writes to the local filesystem.

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?

Four short sentences, front-loaded with the core action, with prerequisite and environment notes following. Every sentence carries information; a slight tightening is possible but there is 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?

For a 7-parameter filesystem-writing tool with no annotations and no output schema, the description covers the workflow prerequisite and conversion option but omits the return value (does it report the saved path?) and overwrite/error semantics. Adequate, but not complete enough for an agent to predict outcomes on edge cases.

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 100%, so every parameter is already documented, including the output_format enum and the convert_quality default. The description only restates the format options ('convert to png, jpeg, or webp') already present in the schema, adding no new meaning. Baseline 3 applies.

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

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

States a specific verb and resource ('Download a single output file to a local path'), and the word 'single' distinguishes it from the bulk sibling download_all_outputs. However, it does not differentiate itself from download_by_filename, which reads as a near-identical operation, so an agent cannot fully resolve between the two from the description alone.

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?

'Use list_outputs to get file info' gives an explicit prerequisite call, and the note about output_format clarifies the optional conversion path. It lacks exclusions — nothing says when to prefer download_by_filename or download_all_outputs — but the positive usage context is clear and actionable.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the blocking/polling model and the environment prerequisite, but says nothing about what happens on partial failure beyond the stop_on_error flag, whether per-workflow results or errors are returned, or how timeouts surface.

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, front-loaded with the action and followed by the execution model and prerequisite. Little waste; the first sentence mildly repeats the tool name but the polling clause immediately 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?

There is no output schema and no annotations, so the description should explain what a batch call returns and how failures are reported. It covers the invocation model (polling, defaults, host requirement) but leaves the result shape and error-aggregation semantics undefined.

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 100%, so every parameter including defaults is already documented in the schema. The description only echoes concurrency and stop_on_error, adding no format or behavior detail beyond the structured fields, so the baseline 3 applies.

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

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

States a specific verb and resource ('Execute multiple workflows in batch') and adds scope detail ('submits each workflow and waits for completion (polling)'), which separates it from the single-workflow siblings. It does not, however, distinguish itself from execute_chain, which is the closest-looking sibling.

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

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

The description gives the precondition 'Requires COMFYUI_HOST' and mentions optional concurrency and stop_on_error, which implies the batch usage context. It never states when to prefer this over execute_workflow, execute_workflow_sync, or execute_chain, so the agent must infer the choice.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses sequencing behavior, the data-passing mechanism, and the COMFYUI_HOST prerequisite, but says nothing about blocking/long-running behavior, what is returned per step (images? JSON?), or how partial failures surface beyond the stop_on_error flag name.

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?

Compact and front-loaded: the core action comes first, then mechanics, then the environment caveat. Every sentence contributes, though the inputFrom/outputTo sentence is dense enough that it could be split for readability.

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

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

For a tool with no annotations and no output schema, the description covers inputs well but never describes the return value — an agent cannot tell whether it gets per-step outputs, a final image reference, or a job id. Given the chaining complexity, that omission leaves a real gap.

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 already 100%, yet the description still adds value: it explains the inputFrom/outputTo pairing concretely with an example and recommends the string form of `workflow` for large payloads. It stops short of explaining step indexing conventions (zero-based) or the outputNode/outputIndex selection, but that meaning is largely in the schema.

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

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

States a specific verb and resource ('Execute a chain of workflows in sequence') and immediately clarifies the chaining semantics ('Each step runs after the previous completes'). This implicitly distinguishes it from execute_workflow and execute_batch, but no sibling is named explicitly, so an agent must infer the boundary itself.

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

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

Gives a clear usage context via the concrete example pipeline (txt2img → upscale → img2img) and a practical hint to prefer saved workflow names for large workflows to avoid ENAMETOOLONG. It lacks explicit 'when not to use this vs execute_batch' guidance, so it falls short of a 5.

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

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

No annotations exist, so the description carries the full burden: it does disclose the asynchronous contract (returns immediately with prompt_id, poll separately) and the environment prerequisite, which is valuable. It says nothing about what happens on invalid workflow, queue-full conditions, or failure modes, which matters for an execution tool with no annotation coverage.

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, front-loaded with the action and return value, then the follow-up tool, then the prerequisite. No filler sentences.

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

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

With no output schema, the description usefully states the return value (prompt_id) and how to retrieve results, and it names required environment state. The main gap is failure/error behavior, but for a single-parameter submission tool this covers what an agent needs to invoke it correctly.

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

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

Schema coverage is 100% and the single 'workflow' parameter is documented with its expected origin (from build_workflow or loaded file). The description adds no further detail about the parameter, so the baseline 3 for high schema coverage applies.

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

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

States a specific verb and resource ('Submit a ComfyUI workflow to run') plus the return value ('Returns prompt_id'), which is more than the bare name conveys. It does not distinguish itself from close siblings like execute_workflow_sync, execute_workflow_stream, or execute_batch, so the agent cannot tell from the description which execution mode to pick.

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

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

Gives a clear next step ('Use get_execution_status(prompt_id) to check result') and states prerequisites (COMFYUI_HOST set, ComfyUI running). It stops short of saying when to prefer this over the sync/stream/batch execution alternatives listed as 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?

With no annotations, the description carries the full burden and does disclose important traits: WebSocket dependency, COMFYUI_HOST requirement, and that it returns a result plus progress event history. It still omits failure behavior, side effects on the queue, and whether execution blocks until completion, so it is only moderately transparent.

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

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

The description is short and front-loads the key purpose and streaming behavior. It is mildly repetitive in mentioning WebSocket support twice, but the redundancy is minor and does not obscure the essential information.

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

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

Given no annotations and no output schema, the description does well to mention return values and environmental prerequisites. However, it does not describe progress event structure, failure modes, or execution side effects, leaving some important context for a streaming execution tool unaddressed.

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 100%, and the description does not add parameter-level meaning beyond what the schema provides. The schema already explains workflow JSON and timeout_ms, so a baseline score of 3 is appropriate.

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

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

The description states a specific action and resource: executing a workflow with streaming real-time progress updates. It distinguishes itself from non-streaming execution siblings by emphasizing streaming and progress monitoring. It could be slightly sharper by explicitly naming the non-streaming alternative, but the core purpose is 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?

It gives a clear use case, 'Use for monitoring execution progress,' and states a prerequisite, WebSocket support. However, it does not explicitly compare against execute_workflow, execute_workflow_sync, or get_execution_progress, leaving the agent to infer when this tool is preferable.

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

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

With no annotations, the description carries the full burden and mostly succeeds: it discloses blocking behavior, WebSocket-with-polling-fallback transport, the three terminal statuses, the COMFYUI_HOST requirement, and the counterintuitive 'error but outputs present' case. It omits what happens to a still-running workflow on timeout and whether the job can be interrupted.

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?

Four sentences, front-loaded with the verb and blocking semantics, then the return shape, then the error-path guidance, then the timeout default. No filler or restatement of the 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?

The description names the returned fields (prompt_id, status, outputs) and covers the error and timeout paths, which compensates for the absent output schema. Remaining gaps are minor: no indication of how large outputs are referenced or what a timeout leaves behind on the server.

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 100%, so all three parameters are already documented in the schema, including the timeout_ms default source and the stream_progress default of true. The description's timeout explanation largely repeats the schema text rather than adding new meaning, so the baseline 3 applies.

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

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

The description opens with a specific verb+resource ('Submit a ComfyUI workflow') and adds the decisive scoping trait that it blocks until completion. It does not explicitly name the sibling alternatives execute_workflow or execute_workflow_stream, so the agent must infer the distinction between sync and streaming variants.

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 actionable guidance on the error path ('when status is error, still check outputs — use download_output or get_last_output') and explains the timeout_ms fallback to get_system_resources. It does not say when to prefer this over execute_workflow_stream, which is the most relevant alternative given the sibling list.

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

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

No annotations are provided, so the description carries the full behavioral burden. It doesn't say whether finalizing mutates workflow state, whether it's idempotent, whether it validates before returning JSON, or what happens on an invalid/unbuilt workflow.

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 sentences, front-loaded with what is returned, then where to use it. No filler, though the parenthetical duplication reference muddies rather than clarifies.

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 whose name implies a state-changing finalize step, with no annotations and no output schema, the description omits the essentials: whether state changes, whether validation occurs, and what the returned JSON represents. An agent cannot safely decide to call this over get_workflow_json.

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 100% and the single workflow_id parameter is already documented as coming from create_workflow. The description adds no extra parameter meaning, so the schema does the work and baseline 3 applies.

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

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

The description says it gets the workflow JSON for a 'dynamic workflow' and equates it to get_workflow_json, but it never explains what 'finalize' means or how finalizing differs from a plain read. Since it explicitly says it's the same as a sibling, an agent can't tell why both exist.

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?

'Use with execute_workflow or save_workflow' hints at the downstream context, which implies this belongs in a finalize-then-run pipeline. It gives no explicit when/when-not versus get_workflow_json, which is the natural alternative for the same output.

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

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

With no annotations, the description carries the burden and does reasonably well: it discloses the data source ('ComfyUI history status.messages'), the prerequisite ('Requires COMFYUI_HOST'), and the shape of the returned error structure. It doesn't explicitly confirm read-only behavior or what happens if the prompt has no errors recorded, which keeps this below 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?

Three tight sentences: purpose with return fields first, usage triggers second, source/prerequisite third. Every sentence carries information, though the parenthetical field list is slightly dense.

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 one-parameter diagnostic tool with no output schema and no annotations, the description covers purpose, triggers, return fields, data source, and an environment prerequisite. Only edge-case behavior (no recorded errors, missing history) is unaddressed.

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 100% and the single prompt_id parameter is documented as coming from execute_workflow or execute_workflow_sync. The description adds no format or sourcing detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get full error details for a prompt') and enumerates what comes back (node_id, exception_type, exception_message, full traceback). This clearly separates it from siblings like get_execution_status and get_history, which report status rather than per-node failure detail.

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 triggers: 'Use when execute_workflow_sync failed or get_execution_status shows errors.' That is a clear when-to-use with named sibling tools. It doesn't state when NOT to use it (e.g., for successful runs or for queue-level failures handled by list_queue), so it stops short of a 5.

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

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

With no annotations, the description carries the full load and does disclose real traits: a WebSocket channel with polling fallback, plus the required COMFYUI_HOST environment dependency. It doesn't say whether the call blocks, how often to poll, or what a failed/unknown prompt_id returns.

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 tight sentences, front-loaded with the verb and resource, followed by the returned fields and then the environment prerequisite. The parenthetical transport note is compressed rather than rambling; no sentence is 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?

No output schema exists, so enumerating status/current_node/progress%/queue_position/outputs is genuinely necessary and is provided. But for a progress-polling tool with zero annotations, the description should also cover invocation cadence and terminal-state behavior, which it omits.

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?

Only one parameter, and the schema documents it at 100% coverage, including that the id comes from execute_workflow or execute_workflow_sync. The description adds nothing about prompt_id syntax or format, so the schema does all the work — baseline 3.

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 concrete verb+resource: 'Get real-time execution progress for a prompt.' That is distinguishable from list_queue or get_history, but it never distinguishes itself from the very similar sibling get_execution_status, leaving the agent to guess which status tool to pick.

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

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

Usage is only implied: 'real-time' and the WebSocket/polling note hint that this is for tracking a run in flight, but there is no explicit 'use this while executing, use get_execution_status when...' guidance. The env prerequisite (COMFYUI_HOST) is a useful condition but is not a when-to-use rule.

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

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

No annotations are provided, so the description carries the full burden. It discloses the environment prerequisite (COMFYUI_HOST) and the shape of returned data, which helps, but says nothing about behavior when the prompt is unknown, whether it waits or is instantaneous, or error conditions.

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, front-loaded with the core action and return contents, with the env requirement last. No filler, though the prerequisite sentence could be tied more tightly to invocation.

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

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

For a one-parameter read tool with no output schema, the description adequately covers what comes back and the environment requirement. Missing only failure/empty-result handling, which is a minor gap at this 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 100% and the single parameter's meaning ('Prompt id returned by execute_workflow') is fully documented in the schema. The description adds no syntax or provenance detail beyond that, so baseline 3 applies.

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

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

States a specific verb and resource ('Get execution status and outputs for a prompt') and enumerates the return payload (status, image filenames, view URLs). It does not explicitly distinguish itself from close siblings like get_execution_progress or get_last_output, so it stops 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?

Usage context is only implied: the prompt_id parameter ties it to a prior execute_workflow call, and it notes the COMFYUI_HOST prerequisite. There is no explicit statement of when to prefer this over get_execution_progress, get_last_output, or get_history.

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

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

With no annotations, the description carries the burden and does disclose a real operational prerequisite: 'Requires COMFYUI_HOST for resource stats,' which tells the agent the resource half of the response may be unavailable without configuration. It also surfaces domain behavior the agent cannot infer from the schema — that SD 1.5/SD XL render text poorly while FLUX and SD 3 do better, which explains why the tool returns model advice at all. Missing are any notes on failure modes beyond the host caveat or on latency of resource probing.

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, front-loaded with the deliverable, then the domain rationale, then the call condition. The middle sentence about base models rendering text poorly is slightly longer than needed but earns its place by justifying the tool's existence rather than being 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?

No output schema exists, and the description compensates by naming the response contents (max resolution, model size, batch, model/setting advice). The only gap is that the specific shape of the resource stats or the form of the advice is not characterized, but for a read-only advisory tool with a fully documented single parameter this is close to sufficient.

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 100% with one optional parameter, so the baseline is 3. The description adds genuine meaning by stating the parameter should be the user's own image description and by explaining the conditional downstream effect (text/letter hints trigger model and setting advice), which goes beyond the schema's restatement.

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

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

The description opens with a specific verb and resource ('Get recommendations for image generation') and immediately enumerates the two payloads: system resource guidance (max resolution, model size, batch) and text-in-image advice. It is clearly distinguishable from siblings such as get_system_resources or suggest_nodes because it fuses resource planning with prompt-conditional model advice.

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 an explicit trigger ('Call when planning a txt2img or img2img workflow') and an explicit conditional ('pass the user's image description as prompt to get text-in-image advice when relevant'). No exclusion against the nearest siblings (get_system_resources, suggest_template_for_checkpoint) is given, so it falls short of the 5 bar.

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

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

No annotations are provided, so the description carries the full burden, and it does well: it discloses the read-only GET semantics via the endpoint, the return payload fields (prompt_id, status, outputs/filenames, elapsed), and the COMFYUI_HOST prerequisite. It stops short of noting ordering, retention, or whether history is cleared, which keeps it at 4 rather than 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?

Three tight sentences: what it does, what it returns, when to reach for it, and the environment prerequisite. No filler, and the scope constraint is front-loaded before the usage rationale.

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

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

With no output schema and no annotations, the description still tells the agent what comes back (prompt_id, status, outputs, elapsed), the environment requirement, and the exact recovery scenario it serves. Nothing an agent needs to invoke it correctly 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 100%, so the single limit parameter is already documented with its default and 1-50 bounds. The description reinforces its meaning with "Returns last N prompts," tying the parameter to ordering of results, which is a small but real addition over the schema.

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

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

States a specific verb and resource ("Get ComfyUI execution history") and even names the underlying endpoint GET /history, plus the no-prompt_id scope. This clearly distinguishes it from execute_workflow_sync and get_execution_status, which return a single run's state rather than a recent-history listing.

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

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

Gives a concrete triggering condition: use when execute_workflow_sync did not return a prompt_id (e.g. WebSocket timeout) to recover the latest run's outputs. It names the sibling and the failure scenario it compensates for, though it does not explicitly say when NOT to use it (e.g. prefer get_execution_status when you already have a prompt_id).

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

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

With no annotations, the description carries the burden and does reasonably well: it discloses the failed-prompt-skipping behavior, the returned fields (prompt_id, filename, subfolder, view_url), and the COMFYUI_HOST prerequisite. It doesn't say what happens when no image output exists at all (empty result vs. error), which is the main remaining behavioral gap.

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?

Four short sentences, front-loaded with purpose then usage then return shape then next step. No filler or restatement 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?

No output schema exists, and the description compensates by listing the returned fields, plus it covers the environment requirement and the follow-up tool. Missing only the empty-result/edge-case behavior, which matters for a recovery-oriented 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?

Zero parameters, so there is no parameter semantics to convey; baseline 4 applies. The description does not waste space inventing 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?

Specific verb+resource ('Get info for the most recent prompt that has image output') with a distinguishing qualifier ('skips failed prompts') that separates it from list_outputs and get_history. An agent can tell exactly what this returns without reading a schema.

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

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

Gives a concrete triggering scenario ('Use when prompt_id was lost (e.g. execute_workflow_sync timed out)') and names the natural follow-up (download_by_filename). It doesn't explicitly name which sibling tool to prefer in other circumstances, but the recovery-workflow 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?

With no annotations, the description carries the behavioral burden, and it does disclose the return shape (name, type, path), the null-if-missing behavior, and the COMFYUI_HOST requirement. It does not state whether the lookup hits a live server, what happens on lookup errors, or confirm read-only semantics beyond the implied verb.

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, zero waste, with the operation and its return contract front-loaded. Each clause 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?

No output schema exists, but the description supplies the return fields and the not-found case, and it flags the host prerequisite. For a simple two-parameter lookup, that covers nearly everything an agent needs, though error behavior is unstated.

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 100% and the enum for type is fully documented, so the schema already does the work. The description adds nothing beyond "by name and type," giving the baseline 3.

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 ("get info for a model by name and type") and enumerates the returned fields, so the agent knows exactly what it retrieves. It does not explicitly distinguish itself from siblings like list_models or check_model_exists, which is why it stops 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 never says when to use this tool instead of check_model_exists, list_models, or get_workflow_models. There is no when/when-not guidance; only the "null if not found" nuance hints at usage.

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

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

No annotations exist, so the description must carry the burden. It usefully discloses that the backend is live ComfyUI when COMFYUI_HOST is set and the knowledge base otherwise, but it omits what 'full node information' contains, error behavior for unknown class names, and freshness implications of the knowledge base fallback.

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 sentences with no wasted words, and the core action is front-loaded before the backend-selection 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?

With no output schema, the description should clarify what fields 'full node information' returns, and it does not. It is adequate for a simple single-param read tool but leaves the return shape and sibling boundaries ambiguous.

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

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

The single parameter has 100% schema coverage, including an example ('e.g. KSampler, CheckpointLoaderSimple'), so the schema already does the work. The description's 'by its class name' slightly reinforces naming but adds nothing beyond the schema.

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

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

States a specific verb and resource: retrieves full node info for a ComfyUI node, keyed by class name. It does not distinguish itself from siblings like get_node_inputs, get_node_outputs, or list_node_types, which an agent must infer.

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?

There is no explicit guidance on when to choose this over get_node_inputs, get_node_outputs, list_node_types, or discover_nodes_live. The COMFYUI_HOST note describes data sourcing, not when the tool should be used.

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

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

With no annotations, the description carries the full burden, and it does disclose one meaningful trait: results come from live ComfyUI when available and fall back to the knowledge base otherwise. That is genuinely useful. However, it says nothing about staleness of knowledge-base data, caching, or what happens when node_name is unrecognized.

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 sentences, zero filler, with the core action front-loaded and the data-source caveat second. Nothing could be removed without losing information.

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

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

For a single-parameter read tool with no annotations and no output schema, the description covers the essential: what is returned (required and optional input definitions) and where it comes from. Minor gap: no indication of result shape or failure behavior for unknown nodes.

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 100% and the single parameter already has an example ('e.g. KSampler, CheckpointLoaderSimple'), so the baseline applies. The description adds no extra meaning about accepted name formats, case sensitivity, or whether class names must be exact.

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: 'Get detailed input definitions for a node', and narrows scope with '(required and optional)'. The 'inputs' framing implicitly separates it from the sibling get_node_outputs, though no sibling is named explicitly.

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

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

Usage is only implied — an agent can infer this is the lookup to run before wiring a node, but there is no explicit 'use when' statement and no routing to alternatives such as get_node_info, which likely overlaps. The fallback sentence touches context but is really about behavior, not selection.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the data source fallback (live ComfyUI when available, otherwise knowledge base), but does not describe error behavior for unknown nodes, response format details, or freshness guarantees.

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 sentences with no wasted words. The core purpose is front-loaded, and the source fallback is stated immediately after.

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

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

For a simple one-parameter read tool with full schema coverage and no output schema, the description adequately states what is returned (output types and names) and where the data comes from. Minor edge cases, such as unknown node handling, are not 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 single parameter has 100% schema description coverage, so the schema already defines node_name with examples. The description only implies that the parameter identifies a node, so baseline 3 is appropriate.

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

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

The description states a specific verb and resource: get output types and names for a node. This is distinguishable from get_node_inputs by its focus on outputs, though it does not explicitly name or rule out 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 no guidance on when to use this tool versus alternatives such as get_node_info or get_node_inputs. The fallback note about live ComfyUI vs knowledge base is operational context, not 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?

With no annotations, the description carries the full burden and does so reasonably: it discloses the COMFYUI_HOST prerequisite, describes the returned fields (flux_ready, platform_hints), and explains the OOM-avoidance motive for calling early. It stops short of describing failure behavior when the host is unreachable or unreachable/invalid.

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, front-loaded with the core purpose and the imperative usage rule before the platform caveats. The Apple Silicon parenthetical is dense but earns its place by preventing a wrong-model choice.

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?

No output schema exists, and the description compensates by naming the key return fields and their meaning (flux_ready threshold ~12GB VRAM, platform_hints). For a simple no-arg probe tool this is close to complete, with only error/edge behavior left unspecified.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for a no-param tool applies. The description correctly implies a parameterless call by framing it as a station-level query.

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 ('Get ComfyUI station resources (GPU/VRAM/RAM)') plus the derived recommendations, which is concrete and readable without the schema. It is not, however, explicitly differentiated from the sibling get_generation_recommendations, which also returns sizing advice.

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 an explicit ordering instruction — 'Call this first before building or executing workflows to avoid OOM' — which is exactly the kind of routing guidance an agent needs. It does not name alternatives or state when the call can be skipped.

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

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

No annotations are provided, so the description carries the full burden, yet it says nothing about read-only semantics (only implied by 'Get'), behavior for invalid or missing workflow ids, or whether the returned JSON is a live snapshot that can drift from the persisted copy. Only the bare minimum is conveyed.

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?

One short sentence, front-loaded with the verb and resource, with no filler. Nothing could be removed without losing information.

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

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

For a single-parameter retrieval tool the description covers the essential shape, and 'workflow JSON' effectively names the return value in the absence of an output schema. It stops short of stating error behavior or whether re-fetching is needed after edits, which an agent would need for reliable chaining.

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 100% and the single workflow_id parameter is documented as 'Workflow id from create_workflow', so the description adds nothing about the parameter. Baseline 3 applies.

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

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

States a specific verb ('Get') and resource ('the current workflow JSON') scoped to a dynamic workflow. The parenthetical naming execute_workflow and save_workflow hints at where the result goes, which helps separate it from list_saved_workflows/load_workflow, though that distinction is never made explicit.

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

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

Usage is only implied: the agent can infer 'call this before execute_workflow or save_workflow'. It never says when NOT to use it, e.g. that load_workflow is the path for previously saved workflows, leaving the sibling overlap unresolved.

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

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

With no annotations provided, the description carries the full behavioral burden and does reasonably well: it states that it scans loader nodes, describes the returned list shape with field names, and clarifies that no ComfyUI connection is needed. It does not discuss malformed workflow handling or whether the operation is strictly read-only, but the core behavior is clear.

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

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

The description is two tightly written sentences. The main action and loader-node examples are front-loaded, followed immediately by the return shape and the no-connection note. There is no wasted text.

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

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

For a single-parameter extraction tool with no annotations and no output schema, the description provides a useful return-shape summary and a key operational note. It is close to complete, though it could say more about edge cases or model-type derivation.

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 only parameter is workflow, and the schema already documents it as a 'Workflow JSON string' at 100% description coverage. The description adds no further syntax, format, or validation detail beyond that, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: extracting required models from a workflow. It also lists relevant loader node classes, making the scope concrete. It does not explicitly distinguish this tool from the nearby check_workflow_models sibling, so it stops 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 usage by explaining that it extracts models from a workflow and notes that no ComfyUI connection is needed. However, it does not say when to choose this tool over alternatives such as check_workflow_models or list_models, leaving the selection context 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?

No annotations exist, so the description carries the full burden. It usefully discloses return values ('Returns nodeIdMap and outputPorts') despite there being no output schema, and it describes the mutation (connecting input ports to existing nodes). It does not cover failure modes, whether the workflow must already exist, or what happens to the connections if insertion fails — a notable gap for a mutating tool with a nested connections object.

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?

Four short sentences, front-loaded with the action and resource before the return-value and prerequisite details. Every sentence carries distinct information — no restatement of the tool name and 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?

For a 3-param mutation tool with a nested object, no annotations, and no output schema, the description does the important work: it explains the operation, the port-connection input, and the returned nodeIdMap/outputPorts needed for downstream connection. It stops short of covering error or existence behavior, keeping it just below 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?

Schema description coverage is 100%, so all three parameters are already documented in the schema, establishing the baseline of 3. The description reinforces the meaning of input_connections ('Connects macro input ports to existing nodes') and the role of workflow_id, but adds no format or syntax detail beyond the schema's own 'Map port name -> [source node id, output index]' 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?

States a specific verb and resource: 'Insert a macro (sub-workflow) into a dynamic workflow.' The parenthetical clarifies the domain abstraction, distinguishing it from add_node's single-node operation, and it names the connection semantics. It doesn't explicitly point at add_node or list_macros as siblings, so a 4 rather than 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?

It gives the ordering prerequisite 'Use workflow_id from create_workflow' and notes the return values are needed to connect macro outputs, which implies the sequencing relative to connect_nodes. However, it never says when to prefer this over add_node, or that list_macros should be consulted first (that hint only lives in the schema param). Usage is implied, not stated.

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

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

With no annotations, the description carries full burden and does disclose real behavioral traits: external cm-cli invocation, hard environment prerequisite (COMFYUI_PATH, ComfyUI-Manager), extra Python dependency ('rich'), and that a ComfyUI restart is required afterward. It does not cover failure behavior, idempotency, or where the nodes land, leaving significant gaps for a mutating install 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?

Four compact sentences, front-loaded with the action and mechanism, then prerequisites and the restart note. The 'rich' dependency sentence is a slightly awkward parenthetical but is genuinely necessary, so little 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?

For a 3-param, no-output-schema install tool, the description supplies the essential operational context: prerequisites, dependency, and the mandatory restart to load nodes. Missing only error/rollback behavior and the meaning of mode/channel, which the schema partly covers.

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 100%, so 'node_names', 'mode', and 'channel' are already documented structurally. The description's examples for node naming add mild reinforcement but nothing about mode ('remote'/'local'/'cache') or channel semantics, so the baseline 3 applies.

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

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

States a specific verb and resource ('Install one or more custom nodes') and names the mechanism (ComfyUI-Manager cm-cli). Concrete examples (ComfyUI-Blip, WAS-Node-Suite) and the contrasting sibling install_model make the scope unambiguous.

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

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

Clearly frames the context in which this tool applies (custom node packs, via Manager) and lists prerequisites: COMFYUI_PATH set, ComfyUI-Manager present, and the 'rich' package installed. It does not explicitly say when NOT to use it or contrast it with alternatives like install_model, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden. It usefully discloses the COMFYUI_PATH dependency and comfy-cli fallback, but it omits important install behaviors such as overwrite handling, authentication requirements, disk write effects, and failure modes.

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

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

The description is front-loaded and efficient, explaining the core action, prerequisite, and fallback mechanism without excessive prose. The final model_type list is somewhat redundant with the schema, keeping it from a 5.

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

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

For an install/mutation tool with no annotations and no output schema, the description covers the main mechanism but is incomplete on side effects and expected outcomes. An agent still lacks guidance on overwrite behavior, return values, and failure handling.

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 100%, so the schema already documents both parameters. The description repeats the model_type values but adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.

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 specific verb+resource: download and install a model by URL. It also enumerates model types, making it clearly distinct from sibling tools like list_models, get_model_info, and check_model_exists.

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 prerequisite context (COMFYUI_PATH) and implementation behavior (comfy-cli fallback), but it does not explicitly say when to use this instead of checking existence first or when not to use it.

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

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

With no annotations, the description carries the full burden and does well: it discloses the side effects (queue polling, prompt removal), the motivated purpose (freeing GPU for the next job), and a config prerequisite (COMFYUI_HOST). It omits error behavior when nothing is running and does not explicitly flag that the running job's work is lost.

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 core action in the first sentence and layers optional behavior afterward with no filler. Slight repetition of the prompt_id condition between sentences but nothing that should be cut.

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 two-optional-parameter mutation with no output schema and no annotations, the description covers action, scoping, cleanup side effect, and the host requirement. What is missing is modest: return/error semantics and confirmation the interrupt takes effect immediately.

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 100%, so both parameters are already documented; the description largely restates them. It adds limited extra meaning, mainly the GPU-freeing rationale for cleanup_after_ms, which is also present in the schema text.

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 ('Stop the currently running workflow on ComfyUI') and clarifies the optional scoping to a single prompt via prompt_id. The role is distinguishable from queue-mutating siblings like clear_queue, though it never names an alternative explicitly.

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 conditions: pass prompt_id to interrupt only that prompt, omit it to interrupt the current run, and set cleanup_after_ms only when prompt_id is provided. It does not call out when to prefer clear_queue/delete_queue_items over this tool, leaving that inference to 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?

No annotations are provided, so the description carries the burden. It discloses the return fields (id, name, description, inputs, outputs) and 'List' implies a safe read-only operation, but it does not explicitly state side-effect behavior, permissions, or pagination.

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 sentences, front-loaded with the core action and followed by the return fields. Every sentence adds useful information with no waste.

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

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

With zero parameters and no output schema, the description does a good job covering purpose and return shape. It is slightly incomplete in not relating the tool to insert_macro, but it provides enough 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?

The tool has zero parameters, so there are no parameter semantics to explain; baseline for zero parameters is 4. The description appropriately does not invent parameter 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 states a specific verb and resource: listing available workflow macros, clarified as built-in sub-workflows. It is clear what the tool does, though it does not explicitly differentiate itself from the related insert_macro sibling.

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

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

Usage is implied by 'List available' and the natural workflow of discovering macros before using one. However, it does not explicitly say when to use this versus insert_macro or list_templates, nor does it name an alternative.

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

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

With no annotations, the description does carry the burden, and it discloses the underlying source (object_info) and an environment prerequisite (COMFYUI_HOST). However it does not state that the operation is read-only, nor anything about return shape or whether the model list is cached/live.

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 tight sentences with purpose first, then the optional filter, then the prerequisite. The enumerated type list mildly duplicates the schema enum, which is the only 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 single-optional-parameter read tool with no output schema, the description covers purpose, data source, and the host prerequisite. Missing only an explicit read-only statement and any hint about response contents, which is acceptable here.

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 100% and the enum fully documents valid values, so the schema already carries semantics. The description merely restates the same enum list without adding format or behavioral meaning beyond it.

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 ("List models available on the ComfyUI server") and names the data source (object_info). It is distinguishable from siblings like get_model_info or check_model_exists, though it never explicitly contrasts with them.

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

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

Usage is implied by "Optionally filter by type (omit for all types)" and the prerequisite "Requires COMFYUI_HOST" is stated, but no alternative tool is named and no when-not guidance is given (e.g. when to use get_model_info or check_model_exists instead).

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

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

With no annotations, the description does carry some weight: it discloses the two data sources, that results are merged and de-duplicated, and implicitly that a live ComfyUI must be reachable. It does not say what happens if ComfyUI is offline, whether the knowledge base fallback still returns partial data, or what shape the categories take.

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 front-loaded sentence with no filler; the merge/uniqueness qualifier is the only extra detail and it 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?

For a zero-argument listing tool with no annotations and no output schema, the description covers source semantics but not the return shape (category name only? ids? counts?). An agent knows what it gets conceptually but not what fields to expect.

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?

Zero parameters, so the schema carries nothing to contradict and the baseline is 4. The description correctly implies no arguments are needed to call it.

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?

Names a specific verb ('List') and a specific resource ('node categories'), plus the two sources merged. This clearly distinguishes it from siblings like list_node_types or list_queue, though it never explicitly says how it differs from list_node_types.

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

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

Usage is only implied: an agent can infer this is a browsing/aggregation step before picking node types. There is no explicit when-to-use, no alternative named (e.g., discover_nodes_live or list_node_types), and no stated prerequisite such as a running ComfyUI 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?

No annotations are provided, so the description carries the full disclosure burden. Saying data comes "from the knowledge base" hints that results may be a synced snapshot rather than live state, which is useful, but nothing is said about read-only safety, result volume/pagination, or staleness relative to sync_nodes_to_knowledge/discover_nodes_live.

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 sentences, zero filler, with the core action front-loaded and the optional filtering trailing. Every clause 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?

For a simple zero-required-parameter read tool with fully documented params and no output schema, the description is minimally adequate. However, with no annotations and no return-value documentation, an agent still lacks confidence about result shape, size, or freshness.

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 100% and both parameters are documented with examples and an enum, so the schema already does the work. The description only restates the filter intent and adds no format or semantics beyond it, which is the baseline 3 case.

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?

Clearly states the verb and resource: lists ComfyUI node types, optionally filtered by category or priority. It also identifies the data source (the knowledge base), but it does not distinguish itself from siblings like search_nodes, discover_nodes_live, or suggest_nodes, which an agent could easily confuse with this tool.

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

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

"Optionally filter by category or priority" implies the enumeration use case, but there is no explicit when-to-use guidance and no mention of alternatives such as search_nodes or discover_nodes_live. An agent must infer when to pick this over the live/search variants.

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

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

No annotations are provided, so the description carries the burden. It does add real value by disclosing the returned fields (prompt_id, node_id, type, filename, url) and the COMFYUI_HOST dependency. However, it does not say what happens for an incomplete or unknown prompt_id, nor whether results are paginated or cached.

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, front-loaded sentences: purpose, return shape, prerequisite. Nothing redundant and the most important information comes first.

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

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

With no output schema, the description compensates by enumerating the returned fields, and it flags the environment prerequisite. Completeness is good for a simple one-parameter list tool; only edge-case behavior (empty results, invalid prompt_id) is unstated.

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?

Only one parameter exists and schema coverage is 100%, with the schema itself explaining the prompt_id source (execute_workflow or execute_workflow_sync). The description adds no format or lineage detail beyond that, so the baseline 3 applies.

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

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

Specific verb+resource with a clear scope qualifier: 'List all output files (images, gifs) for a completed prompt.' An agent can tell this apart from download_output or get_last_output by the 'list' vs 'download/get' distinction, though no sibling is named explicitly.

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 'for a completed prompt' implies usage after an execution finishes, but there is no explicit when/when-not guidance and no pointer to download_output or download_all_outputs as the follow-up step. The agent must infer the workflow position.

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

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

With no annotations, the description carries the behavioral burden. It discloses the data source and returned content, and “List” implies a read-only operation, but it does not explicitly state side effects, permissions, or refresh behavior.

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

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

It is a single front-loaded sentence with no wasted wording. The parenthetical source path adds useful specificity without bloat.

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 parameterless list tool without an output schema, the description adequately explains what is returned: loaded plugins plus counts of contributed macros/templates. Minor details such as ordering or exact output shape are omitted but not essential.

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

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

The tool has zero parameters, so there are no parameter semantics to explain. Per the baseline for parameterless tools, a 4 is appropriate.

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

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

The description states a specific verb and resource (“List loaded plugins”), identifies the source path, and says it returns macro/template counts. It is clear, though it does not explicitly distinguish itself from siblings such as reload_plugins or list_macros.

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 no explicit when-to-use guidance, prerequisites, or alternatives. The listing intent is implied by the verb, but there is no routing guidance versus reload_plugins or other list tools.

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

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

With no annotations, the description carries the full behavioral burden. 'List' implies a read-only operation, and the scope (running and pending prompts) is disclosed, but it does not describe permissions, side effects, output shape, or rate/behavioral constraints.

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 sentences, front-loaded with the core purpose and followed by the prerequisite. There is no wasted text.

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

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

For a zero-parameter list tool with no output schema, the description supplies the essential purpose and the host prerequisite. It could say more about the queue contents or output format, but it is adequate 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?

There are zero parameters, so the baseline is 4. The description adds an environment prerequisite (COMFYUI_HOST) that is not represented in the empty input 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 states a specific verb and resource ('List current ComfyUI queue') and clarifies scope by naming running and pending prompts. It is clear but does not explicitly distinguish itself from siblings such as get_execution_status or clear_queue.

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 prerequisite 'Requires COMFYUI_HOST' gives useful setup context, but the description does not say when to use this tool versus alternatives like get_execution_status or get_execution_progress. Usage is implied only.

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

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

With no annotations, the description carries the disclosure burden; it does say the tool reads a specific directory and returns names and paths, which conveys it is a benign read and hints at output shape. It omits what happens when the directory is empty or missing, whether paths are absolute or relative, and whether it recurses subdirectories.

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 short sentence with no padding, and the return contents (names and paths) are front-loaded. It is perhaps slightly under-specified rather than overly long.

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

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

For a zero-parameter list tool with no annotations or output schema, the description gives only a minimal sketch of the return value. It lacks the source specificity (absolute vs relative paths, recursion, ordering) or follow-up guidance an agent would need to use the results reliably.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The description correctly indicates nothing needs to be supplied and no filtering options exist.

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

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

The description states a specific verb and resource (list saved workflows) and specifies the source location (workflows/ directory). It implicitly distinguishes from list_templates by scoping to saved workflows, but never names the sibling tools it is not (e.g., load_workflow) or what 'saved' means precisely.

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

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

Usage is only implied: an agent can infer this is the way to discover existing workflows before loading or building one. There is no explicit when-to-use, no mention of load_workflow as the follow-up, and no statement about when this is preferable to list_templates.

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

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

With no annotations, the description carries the full burden, and it does add one genuinely useful behavioral fact: 'No ComfyUI connection needed', telling the agent this works offline/without a running server. It says nothing about whether the list is static vs. refreshed, or whether ids are stable across versions.

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 sentences, front-loaded with what is returned, followed by the one non-obvious operational fact. Zero 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 no-param, no-output-schema listing tool this is nearly complete: it names the return content and the connection requirement. A brief note on whether template names/descriptions accompany the ids would close the last gap.

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

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

The tool takes zero parameters, so the baseline is 4; there is no parameter semantics to explain and the description correctly focuses on output instead.

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 ('List available workflow template ids') and gives a concrete example ('e.g. txt2img'), so the agent knows exactly what comes back. It does not explicitly differentiate itself from create_template / apply_template / suggest_template_for_checkpoint, which keeps it 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?

Usage is only implied: listing ids logically precedes apply_template, but the description never says 'use this before apply_template' or excludes the sibling suggest_template_for_checkpoint. An agent can infer the workflow but no condition is stated.

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

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

No annotations, so the description carries the burden: it discloses the filesystem resolution model and that the result is workflow JSON, which is the important part for a read operation. It does not say what happens when the name/path does not exist (error vs. empty) or how relative vs. absolute paths are handled, which an agent dispatching on a string needs to know.

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, zero filler, with the resolution behavior front-loaded followed by the return value and downstream use. Nothing can be removed without losing 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?

With one fully-documented parameter and no output schema, the description covers what the tool does and what it returns, which is most of what an agent needs. The remaining gap is failure behavior for a bad name or path.

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 100% and the single parameter is already documented, so baseline 3 applies. The description adds genuine value on top by explaining the name-to-file mapping (workflows/<name>.json, without extension) and that a full path is also accepted, clarifying the polymorphic 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 specific verb and resource ("Load a saved workflow") and even the resolution rules (name resolved to workflows/<name>.json, or a full path). It names the two downstream consumers (execute_workflow, save_workflow), which separates it from siblings like list_saved_workflows and get_workflow_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?

"Returns workflow JSON for use with execute_workflow or save_workflow" gives a clear picture of where this tool sits in a pipeline. It lacks an explicit when-not clause (e.g. use list_saved_workflows to enumerate available names first), so it falls short of a 5.

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

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

No annotations are supplied, so the description carries the whole burden, and it does disclose the important side effect: it uploads into the ComfyUI input folder, and it requires COMFYUI_HOST. It does not explain what happens if the prompt has no image, or whether an existing file with the same name is overwritten.

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 that open with the action and the side effect, then state the return value, then the precondition. Nothing is repeated and 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?

With one required parameter and no output schema, the description fills the return-value gap by naming the filename to use in LoadImage, and it names the follow-up workflow context. Only edge cases (no image present, filename collision) are unaddressed.

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 documents prompt_id at 100% coverage, and the description adds meaning on top of it: the id comes from execute_workflow, and the run must already be completed with image output. For a tool with a single parameter, this is as much semantics as an agent needs.

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

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

The description states a specific verb and resource: it fetches the first output image from a completed prompt and uploads it to the ComfyUI input folder, returning the filename. That sequence is clearly distinguishable from siblings such as download_output/get_last_output, which retrieve files rather than staging them for a 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?

"Use after get_execution_status confirms the prompt finished with image output" gives an explicit precondition and names the sibling to check first. The text does not say when not to use this tool or which alternative to pick when only downloading is needed, so it falls short of a full advisory.

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

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

With no annotations, the description carries the behavioral burden and does disclose the critical side effect: it kills the process on the ComfyUI port and starts main.py from COMFYUI_PATH. It also covers required environment variables and post-restart sync behavior, but does not mention downtime, running-workflow interruption, or failure behavior.

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

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

The description is front-loaded with the core action and is generally efficient. The sync behavior is mentioned twice, once in the opening and again in the final sentence, which is slightly redundant but not harmful.

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 restart tool with no annotations and no output schema, the description is substantially complete: it covers prerequisites, the destructive process action, and the follow-up sync path. It could be stronger by noting the impact on running jobs or expected return behavior, but the critical context is present.

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 100%, so the three parameters are already documented in the schema. The description adds only a brief mention that sync_after_restart can be set to true; it does not materially explain wait_for_ready or wait_timeout_ms beyond what the schema provides.

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

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

The description states a specific verb and resource: restart ComfyUI so newly installed custom nodes are loaded. It also distinguishes the related sync step by naming sync_nodes_to_knowledge and the sync_after_restart option, so an agent can tell it apart from the sync and plugin-reload 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?

It says when to use the tool: after custom nodes are installed and need to be loaded. It also points to sync_nodes_to_knowledge after restart or the sync_after_restart parameter, though it does not explicitly contrast itself with reload_plugins or state when a restart should be avoided.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the read source (plugins/*/plugin.json) and one side effect (macro registry refresh), but says nothing about whether the reload interrupts in-flight executions, whether a restart is required, whether it can fail on a malformed manifest, or what it returns.

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 tight sentence with the action and its effect front-loaded and no filler. Nothing could be removed without losing information.

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

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

For a zero-argument, no-output-schema tool this is minimally adequate: the agent knows what is reloaded and what is refreshed. It is missing the operational context that matters most for a state-refreshing tool — safety during active executions and expected outcome — which no annotation or output schema supplies.

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?

Zero parameters, so the baseline is 4; the schema is trivially complete. The description adds only the path glob, which is context rather than parameter semantics, so it neither gains nor loses here.

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?

Specific verb ('reload') plus resource ('plugins') and the exact source of truth ('plugins/*/plugin.json'), with the secondary effect ('refresh macro registry') stated. It is distinguishable from list_plugins and list_macros, though it does not explicitly contrast with reload_comfyui, the closest sibling.

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

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

The description never says when to invoke this tool — e.g. after editing a plugin manifest or installing a plugin — nor when not to. It also fails to distinguish it from reload_comfyui or to point at list_plugins as the inspection alternative, leaving the agent to infer the trigger condition.

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

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

With no annotations, the description carries the burden and does meaningful work: it discloses that references are not fixed and that validation will surface dangling refs afterwards. It leaves unstated whether connected edges are cascaded away, whether removal is irreversible, and what the response contains.

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 sentences, zero filler, and the key limitation is front-loaded right after the action so it can't be missed. Every clause 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?

For a two-parameter mutation with no output schema or annotations, the description covers the critical gotcha (dangling references needing validation). Minor gaps are the lack of return/pagination info and the unstated fate of connected edges.

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 100%, and both params (workflow_id, node_id) are already documented in the schema, including the 'from create_workflow' hint. The description adds no additional parameter meaning, so baseline 3 applies.

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

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

The description names a specific verb and resource ('Remove a node from a dynamic workflow') and clearly distinguishes it from sibling mutations like add_node or connect_nodes without needing to name them explicitly. It stops short of an explicit 'don't use for X' contrast, but the operation is unambiguous.

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

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

The caveat that validation will report dangling refs implies the follow-up validate_workflow call, and the workflow context tells an agent where this fits. However, it never states prerequisites (e.g., workflow must exist/be editable) or when to remove versus rewire a node.

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

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

With no annotations the description must carry the behavioral burden; it does disclose the write target and that a path is returned. However it never addresses whether an existing file with the same name is overwritten, whether the directory is created, or what failures look like — the key risk for a file-writing mutation.

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 tight sentences: action and destination first, return value second, lifecycle guidance last. No filler and nothing buried.

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 two-parameter tool with full schema documentation and a stated return value, the only missing piece is overwrite/idempotency behavior. Otherwise an agent has everything needed to call 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 coverage is 100%, so both parameters and the .json suffix rule are already documented in the schema. The description adds only the path pattern, which largely duplicates that, so baseline 3 applies.

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

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

States a specific verb and resource ('Save a workflow JSON to file') plus the concrete destination pattern workflows/<name>.json, which lets an agent picture the effect. It is clearly a persistence step distinct from create_workflow/finalize_workflow, though those siblings are never named for contrast.

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?

'Use after build_workflow to persist for later load_workflow or execute_workflow' gives an explicit lifecycle position and names the follow-on tools. It does not say when to prefer this over create_workflow or finalize_workflow, which are the closest ambiguous 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that nodes are searched across both live ComfyUI and the knowledge base and that live results override KB results for the same class. However, it does not describe result ordering, pagination, return shape, or failure behavior, which are relevant for a no-annotation search tool.

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

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

The description is two sentences and front-loads the primary action before the source and override behavior. Every sentence carries useful information, with no redundant or filler text.

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

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

The tool has four optional parameters with full schema descriptions and no output schema. The description covers the core search scope and source override behavior, but it does not clarify the return format or how live versus KB results are presented. For a search tool without annotations or an output schema, it is adequate but leaves some operational gaps.

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

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

Schema description coverage is 100%, so the schema already defines the query and each filter parameter with examples. The description adds only a high-level summary of those same parameters and does not add syntax, matching semantics, or precedence beyond the schema. With high schema coverage, this meets the baseline 3.

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

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

The description states a clear verb and resource: search nodes by query string and optional filters. It also specifies that the search spans live ComfyUI and the knowledge base, with live overriding KB for duplicate classes. It does not explicitly differentiate itself from nearby siblings such as discover_nodes_live, suggest_nodes, or list_node_types, which keeps it below 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?

Usage is implied by the query-and-filter framing, but there is no explicit when-to-use guidance versus sibling tools. The description does not say when to prefer search_nodes over discover_nodes_live, suggest_nodes, or list_node_types. It provides enough context to infer basic usage but leaves routing decisions to 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 no annotations provided, the description carries the full burden and does disclose the important mutation detail that existing values or links are overwritten. However, it does not cover permissions, validation behavior, error conditions, or workflow lifecycle requirements.

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

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

The description is a single front-loaded sentence with no wasted language. It communicates the action and overwrite behavior efficiently.

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 schema is complete, which lowers the burden on the description, but this mutation tool has no annotations and no output schema. The description would be stronger if it clarified lifecycle expectations and overwrite implications.

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 100%, so the schema already documents all four parameters, including the value format for links. The description adds little parameter-specific meaning beyond the schema baseline.

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

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

The description uses a specific verb and resource: it sets a literal input on a node in a dynamic workflow, and it notes that this overwrites an existing value or link. That distinguishes it from link-creation tools like connect_nodes, though it does not name alternative siblings explicitly.

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?

There is no explicit guidance on when to use this tool versus alternatives, nor on prerequisites such as workflow creation or finalization. The usage context is only implied by 'dynamic workflow' and the overwrite behavior.

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

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

No annotations are provided, so the description must carry behavioral context. 'Suggest' and 'search' imply a read-only discovery operation, but the description does not explicitly state read-only behavior, result ranking, limits, or what the suggestion output looks like.

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

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

The description is a single compact sentence that front-loads the tool's purpose. It is efficient, though it could be structured slightly better to clarify the two modes.

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 two-parameter discovery tool, the description is minimally adequate. However, with no annotations and no output schema, it should say more about return behavior and selection relative to sibling search tools.

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 100%, so both parameters are already documented. The description reinforces that task_description searches by description/use_cases and input_type matches output type, but adds little beyond the schema.

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

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

The description gives a specific verb ('Suggest'), resource ('ComfyUI nodes'), and two distinct modes: task/use-case text and output type. It is clear what the tool does, though it does not differentiate itself from siblings such as search_nodes or discover_nodes_live.

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 implies two usage modes (by task description/use_cases or by output type), but does not state when to prefer this over search_nodes, discover_nodes_live, or list_node_types. The usage is inferable but not explicitly guided.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the core mapping logic (FLUX to txt2img_flux, SD XL/SD 1.5 to txt2img) but does not say what happens for unknown checkpoints or what exactly is returned.

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

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

The description is three tightly written sentences with the core mapping logic front-loaded. Every sentence contributes either the purpose, the mapping rule, or the call sequence.

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

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

For a simple one-parameter suggestion tool with full schema coverage, the description gives enough context to invoke it correctly. The main remaining gaps are the exact return value and fallback behavior for unrecognized checkpoints.

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 100%, so the ckpt_name parameter is already documented. The description reinforces that the parameter is a checkpoint filename and determines the suggested template, but adds little parameter-level detail beyond the schema.

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

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

The description states a specific verb and resource: suggesting a workflow template from a checkpoint filename. It also names the concrete template outputs (txt2img_flux or txt2img), so the agent can distinguish this from build_workflow and other sibling tools.

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

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

It gives a clear usage condition: call before build_workflow when the user did not specify a template. It does not explicitly name alternatives such as list_templates or state when not to use it, but the sequencing guidance is strong.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses that the operation is additive-only (skips existing entries, so no overwrite/removal risk), that it creates a knowledge/ directory as a side effect, and that a running ComfyUI instance is required. It stops short of saying whether the operation is idempotent under partial failure or what filesystem permissions are needed.

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 dense sentences, front-loaded with the core action and each sentence contributing a distinct fact (behavior, destination, prerequisite). The parenthetical env-var aside slightly interrupts the flow but does not waste space.

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

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

For a zero-parameter mutation tool with no output schema and no annotations, the description covers purpose, additive semantics, directory creation, and the runtime prerequisite. The main remaining gap is what the call reports back (e.g. how many nodes were added), which matters for verifying success.

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?

Zero parameters means the baseline is 4. The description adds a valuable non-schema input — the COMFYUI_KNOWLEDGE_DIR environment variable that controls the destination directory — information the empty schema cannot convey.

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+scope: sync node definitions from a running ComfyUI into the knowledge base, with the additive behavior spelled out ('adds only nodes that are not already in base-nodes.json'). It is distinguishable from read-only siblings like list_node_types or discover_nodes_live, though it never names an alternative tool.

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

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

Gives a hard prerequisite ('Requires ComfyUI to be running') and a configuration hint (COMFYUI_KNOWLEDGE_DIR), which implies when the tool is usable. However it never states the situational trigger (e.g. after installing custom nodes) or contrasts with discover_nodes_live / list_node_types, leaving the agent to infer when this is the right call over 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?

No annotations exist, so the description bears the full burden. It does not state whether the tool is read-only, whether it returns a boolean, an error list, or throws on failure, nor what happens with unknown or extra parameter names. For a validation tool, the shape of the failure result is the single most important behavioral fact and it is absent.

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?

One sentence, front-loaded with the verb, no filler. It is appropriately short, though the brevity is partly the cause of the missing return-behavior 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?

With no annotations and no output schema, the description is the only source of information about the result, yet it says nothing about return values or failure reporting. It also does not explain how 'values' maps onto a template's declared parameters, which matters given nested-object input.

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 100%, so the schema already documents both 'template' and 'values'. The description adds only that the template carries required params and types, which is mild added context beyond the schema's 'Template JSON string' — baseline 3 is appropriate.

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: validate parameter values against a workflow template, with a parenthetical naming what it checks (required params, types). This distinguishes it from validate_workflow, which validates the workflow graph itself, though the description does not make that contrast explicit.

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

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

The word 'validate' implies a pre-flight check before applying or building a workflow, but the description never says when to call it, what to do with the result, or how it relates to siblings like validate_workflow and apply_template. Usage is only inferable.

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

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

With no annotations provided, the description carries the full burden; it does disclose the two categories of checks performed, which is real behavioral content beyond the name. However, it says nothing about what happens on failure (error list? raise?), whether it is read-only, or whether it mutates the workflow, leaving meaningful gaps for a no-annotation tool.

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

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

A single front-loaded sentence with the scope of validation following the colon; every clause earns its place. It is arguably too terse rather than padded, but structurally clean.

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

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

For a simple one-parameter tool with no annotations, the description covers purpose but omits the return semantics (valid/invalid shape, error reporting) and workflow-state prerequisites, which matter since there is no output schema to fall back on.

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 100% and the single workflow_id parameter is already documented as coming from create_workflow, so the description adds nothing beyond the schema. Baseline 3 applies when the schema does the work.

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 (validate) and resource (workflow) and enumerates what is checked: node references exist and output indices are valid. This distinguishes it from siblings like check_compatibility or validate_template_params, though it never explicitly names those alternatives.

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?

There is no guidance on when to call this versus check_compatibility or finalize_workflow, and no statement about ordering (e.g., before execute_workflow) or when validation is unnecessary. Usage is only inferred from the tool name.

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