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

No annotations present, so description carries full burden. It discloses that the tool returns a text summary (not raw JSON) optimized for AI reasoning and that it loads a saved workflow. It does not explicitly state non-destructiveness but implies read-only analysis. Minor gap in stating side effects or permissions, but overall 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 three sentences, front-loaded with purpose and key details. No unnecessary words; every sentence adds value. Highly concise and well-structured.

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 output schema, 3 parameters, and no annotations, the description adequately explains the tool's function, output format (text summary), and use case. Could elaborate on return structure, but the summary is sufficient for reasonable understanding. Minor gap for completeness.

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

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

Schema has 100% coverage with detailed parameter descriptions (e.g., view enum meanings, filename usage). The tool description adds high-level purpose but does not add meaning beyond the schema. 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 clearly specifies the verb 'load' and 'return a structured analysis', identifies the resource 'workflow', and details output components (sections, node settings, connections, data flow). It explicitly distinguishes from sibling tool get_workflow, which returns raw 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?

The description explicitly states when to use this tool ('understand any workflow before modifying or executing it') and when not to ('unless you need the raw JSON for enqueue_workflow or modify_workflow'), providing clear guidance against 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 full burden. It states the action (cancel) but does not disclose side effects, irreversibility, or consequences like loss of progress. Minimal behavioral transparency.

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

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

The description is two sentences with no fluff, front-loading the purpose. Every sentence is meaningful and appropriately sized for the tool's simplicity.

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

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

For a simple tool with one optional parameter and no output schema, the description is largely sufficient. Could explicitly mention that it only works on running jobs (not queued) but sibling names provide that context.

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

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

Schema coverage is 100% and the description adds no new meaning beyond repeating the schema's parameter description. Baseline applies as description provides no extra semantic value.

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

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

The description clearly states the verb 'interrupt/cancel' and the resource 'currently running ComfyUI job', with an optional parameter for targeting a specific job. It effectively distinguishes from siblings like cancel_queued_job and 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 description implies usage context (interrupt current or specific running job) but does not explicitly state when not to use or mention alternative tools. Context from sibling names partly compensates.

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?

Without annotations, the description carries the full burden. It clearly states the tool removes pending jobs and does not affect running ones, which is transparent about its scope. However, it lacks details such as whether the action is destructive, requires permissions, or produces any feedback (e.g., success/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 a single, front-loaded sentence that efficiently conveys the primary action and key constraint. No wasted words.

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

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

For a simple tool with one parameter and no output schema, the description is complete. It adequately covers what the tool does and its limitations (only pending jobs), which is sufficient for an agent to invoke it correctly.

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

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

The schema covers 100% of parameters with a description for 'prompt_id'. The description adds no extra meaning beyond the schema, simply restating the parameter's purpose. Baseline 3 is appropriate since schema does the heavy lifting.

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

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

The description clearly states the verb 'Remove', the resource 'a specific pending job', and specifies the identifier 'by prompt_id'. It explicitly distinguishes itself from sibling tools by noting it does not affect running jobs, which differentiates it from 'cancel_job' and '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 description explicitly says it only affects pending jobs, implying when to use it. However, it does not explicitly state when not to use it (e.g., for running jobs) or mention alternative tools like 'cancel_job' for running jobs. Still, the context is clear enough for correct 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 full burden. It transparently discloses that the tool clears pending jobs but leaves the current job unaffected. However, it does not mention whether the action is destructive or if any confirmation is required.

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

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

Two sentences with no superfluous words. The first sentence immediately states the action and target, making it front-loaded and efficient.

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 parameters and no output schema, the description adequately covers the behavioral scope and key constraint, making it complete for an agent to understand its effect.

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 no parameters, and the description adds value by clarifying the scope ('all pending jobs') and the constraint ('does not affect currently running job'), which goes beyond the empty schema.

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

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

The description clearly identifies the verb 'Clear' and the resource 'all pending jobs from the ComfyUI queue'. It differentiates from sibling tools like 'cancel_job' by specifying it clears all pending jobs and does not affect the currently running job.

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

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

The description states the tool's purpose and the scope (all pending jobs, not running job). It implies usage for clearing the entire queue, but does not explicitly contrast with sibling tools like 'cancel_queued_job' for selective cancellation.

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 optional behavior (unload only models or only memory) but does not mention potential side effects (e.g., impacting running jobs, requiring no pending generations). The description is adequate but not fully 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?

Three sentences, each serving a distinct purpose: purpose, usage, options. No redundancy or filler. The description is front-loaded with the primary action and efficiently provides all necessary context.

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 output schema and a simple action, the description covers when to use, what it does, and parameter options. It could mention that it is a resource management tool with no effect on workflow definitions or job queues, but it is sufficiently complete for the tool's simplicity.

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% with clear boolean descriptions. The description adds value by explaining that you can choose to unload only models or only memory, which clarifies the independent usage of the parameters beyond what the schema states.

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

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

The description clearly states the action ('Free GPU VRAM'), the resource ('cached models from ComfyUI'), and the context. It distinguishes the tool from siblings that deal with workflows, jobs, or images, making its purpose unambiguous.

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

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

The description provides explicit usage scenarios: between generation runs with different model families or when low on VRAM. It gives concrete examples (SDXL to Flux). It could be improved by mentioning when not to use (e.g., during active generation), but the guidance is solid.

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 cover behavioral traits. It states 'creates' and 'returns JSON', but does not disclose side effects (e.g., persistence, overwriting), authorization requirements, or whether the workflow is saved. This leaves some ambiguity.

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 with no wasted words. It front-loads the action and purpose, then lists templates and output. Highly efficient.

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 2-parameter tool with one required and no output schema, the description adequately covers purpose, available templates, and return value. It could mention whether 'params' is optional or how they affect the workflow, but overall complete enough.

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%, but the description adds meaning by listing example parameter keys for 'params' (e.g., checkpoint, positive_prompt), which the schema only marks as additionalProperties. This helps the agent understand what can be passed.

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

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

The description clearly states the tool creates a ComfyUI workflow from a named template, lists all available templates, and indicates the output (complete workflow JSON). This distinguishes it from siblings like dsl_to_workflow or modify_workflow.

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

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

The description explicitly lists the six available templates, guiding when to use the tool. However, it does not mention when not to use it or compare with alternatives like modify_workflow or dsl_to_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?

With no annotations provided, the description carries the full burden. It clearly states the destination directory and acceptable URL sources. However, it does not disclose whether existing files are overwritten, or any permissions or size limitations, which would be useful for a download operation.

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

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

Single sentence that is front-loaded with the core action and destination. No wasted words. Very concise.

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

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

Given the tool's relative simplicity, the description covers the main context. There is no output schema, so return values are not explained, but that is acceptable. One could argue for mentioning success/error feedback, but overall it is sufficiently 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 baseline is 3. The description adds value by clarifying that the url is a direct download link, that filename auto-detects from URL if omitted, and that target_subfolder is an enum with examples like 'checkpoints', 'loras', etc. This provides meaning 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?

Description explicitly states the tool downloads a model file to the ComfyUI models directory from a URL, mentioning both HuggingFace and direct links. This clearly distinguishes it from sibling tools like list_local_models or search_models.

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

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

The description implies usage for downloading models from specific URL types but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. Sibling tools like search_models or list_local_models exist, but no comparative guidance is given.

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

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

No annotations provided, so description carries full burden. Describes transformation behavior and notes experimental. However, lacks details on error handling, validation, or side effects on invalid input.

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 efficient sentences, front-loaded with action and resource. No wasted words, includes cross-reference to sibling 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?

Adequate for a simple conversion tool with one parameter and no output schema. Describes input, output format (API JSON), use case, and experimental status. Could specify if output is directly enqueueable.

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?

Single parameter 'dsl' documented in schema with 'Workflow DSL text'. Description adds no extra detail beyond schema. Coverage is 100%, 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?

Clearly identifies action (convert), resource (DSL to workflow JSON), and distinguishes from sibling tools like workflow_to_dsl (inverse) and enqueue_workflow (consumer).

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 context for when to use: after authoring DSL, before enqueue_workflow. Mentions experimental nature. Could be more explicit about when not to use (e.g., if workflow already exists in API format), but sufficient.

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

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

With no annotations, the description carries full burden. It accurately discloses the asynchronous behavior (immediate return without waiting) and what the tool returns. However, it does not mention error handling or validation behavior for invalid workflows, which is a minor 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?

Two sentences with no waste. First sentence front-loads the core action and immediate return; second sentence elaborates on async behavior and next steps. 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?

For a tool with 2 parameters and no output schema, the description adequately explains the immediate return values (prompt_id and queue position) and subsequent workflow. It could mention potential error cases, but overall it is sufficiently complete for a submission tool.

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

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

Schema coverage is 100% with descriptive names and descriptions for both parameters. The description adds no additional meaning beyond what the schema already provides, 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 clearly states the verb 'Submit' and resource 'ComfyUI workflow', specifying it returns immediately with 'prompt_id and queue position'. It distinguishes itself from sibling tools like get_job_status and get_history by mentioning them as alternatives for later progress/results.

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

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

Explicitly says 'Does not wait for completion' and directs the agent to use get_job_status for progress and get_history for results, providing clear when-to-use and when-not-to-use 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?

Describes building a txt2img workflow, filling unspecified parameters from defaults, auto-selecting checkpoint, and async return of prompt_id with later notification of asset_id. No annotations provided, so description carries full burden. Missing details on error handling or rate limits, but sufficient for typical usage.

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 paragraph of four sentences, each adding value: purpose, behavioral details, return value handling, and alternative for more control. No redundant or unnecessary words.

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

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

Given 11 parameters, no output schema, and no annotations, the description explains the async flow and how to get results. It covers defaults, checkpoint auto-selection, and ties to other tools. Could be slightly more detailed on potential failures, but sufficient for a high-level entry point tool.

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

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

Schema coverage is 100% with all parameters documented. The description adds minimal new parameter info beyond noting auto-selection of checkpoint and use of defaults, which is already in schema descriptions. 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 clearly states the tool generates an image from a text prompt as the high-level entry point. It specifies the verb 'generate' and resource 'image from text prompt', and differentiates from siblings like create_workflow + enqueue_workflow for full control.

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 tells when to use this tool (high-level entry point) and when not (for full node graph control use create_workflow + enqueue_workflow). Also mentions return behavior and how to use completion notification with view_image or regenerate.

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 fully disclose behavior. It does not mention whether the tool modifies anything, permissions needed, or what happens when 'install_in' is omitted (e.g., saving to current directory or returning content). This leaves significant ambiguity for an agent.

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

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

The description is two sentences, front-loaded with the main action, and contains no unnecessary words. Every sentence adds meaningful 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 no output schema, the description should clarify what the tool returns or produces. It mentions generating a file but does not specify whether it returns the file path, content, or just creates it. The optional 'install_in' parameter hints at file creation, but behavior without it is undefined. Missing details on overwrite behavior or error 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 coverage is 100%, so the baseline is 3. The description adds clarity by explaining the 'source' parameter accepts Registry IDs or GitHub URLs, but adds little beyond the schema's existing description. No additional guidance on 'install_in' 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 clearly states the tool analyzes a ComfyUI custom node pack and generates a skill file. The verb ('analyze and generate') and resource ('custom node pack, skill file') are specific, and it distinguishes from siblings like 'get_node_pack_details' by focusing on skill file creation.

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 specifies acceptable source formats (Registry ID or GitHub URL), implying when to use the tool. However, it does not explicitly mention when not to use it or provide direct alternatives, but the context is clear enough for an 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, the description carries the full burden. It discloses that returns are asynchronous (prompt_id immediately, asset_id later), and mentions fallback defaults and auto-resolution for checkpoint and controlnet_model. Missing details on potential errors or rate limits.

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 purpose, no redundancy. Each sentence earns its place: purpose, prerequisite, and return behavior.

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 13 parameters and no output schema, the description covers the workflow outline but lacks parameter ranges, defaults, and output format details. It is adequate but not 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 coverage is low (38%). The description adds context by explaining auto-resolve and fallback behavior, but it does not describe most parameters (e.g., cfg, seed, steps). It partially compensates but is insufficient given the low coverage.

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

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

The description clearly states the tool's purpose: generating images conditioned by a ControlNet preprocessed image plus a text prompt. It distinguishes itself from siblings like generate_image and generate_with_ip_adapter by specifying the ControlNet conditioning.

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

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

The description provides clear context on when to use the tool (with a ControlNet preprocessed image) and gives a prerequisite step (upload control image first with upload_image). However, it does not explicitly list alternatives or scenarios where other tools are better.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool requires custom nodes, defers to default values, auto-resolves checkpoints, and returns a prompt_id immediately with asset_id arriving later. While it doesn't address destructive/revertibility or rate limits, it covers the key behavioral traits relevant for a generation 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 concise—five sentences—with each sentence adding essential context. It front-loads the purpose and then provides step-by-step guidance, return behavior, and dependency notice. No extraneous information exists.

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 13 parameters, 2 required, and no output schema, the description covers the critical workflow (upload first, then use filename), explains auto-resolution of defaults and checkpoint, and describes the return pattern. It lacks specifics on how to retrieve the final asset beyond the notification, but overall it provides sufficient context for an agent to use the tool correctly.

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

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

Schema description coverage is only 38%, so the description must compensate. It adds meaning for reference_image (filename of already-uploaded image), checkpoint (auto-selected if omitted), and explains fallback defaults. However, many parameters (cfg, seed, steps, width, height, sampler, scheduler, negative_prompt) are not elaborated beyond their schema names/types, leaving gaps. The description adds some value but not enough to fully compensate for low coverage.

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

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

The description explicitly states the tool's purpose: generating an image guided by a reference image's style/subject via IP-Adapter plus a text prompt. It clearly distinguishes from sibling tools like generate_image and generate_with_controlnet by specifying the IP-Adapter mechanism and the need for a reference image.

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

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

The description provides clear usage steps: upload the reference image first using upload_image, then pass its filename as reference_image. It notes the requirement for custom nodes (ComfyUI_IPAdapter_plus) and mentions that unspecified parameters fall back to defaults and checkpoint auto-resolves. This offers good guidance on when and how to use the tool, though explicit when-not-to-use scenarios are absent.

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 provided, so description bears full burden. It accurately describes a read-only operation ('Show...tracking statistics'), with no hidden side effects or permissions implied. However, it does not mention data freshness or rate limits.

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?

Description is a single, efficient sentence with no wasted words. It front-loads the purpose and includes key details (total runs, unique combos, breakdown).

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

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

For a simple tool with one optional parameter and no output schema, the description covers the essential functionality. However, it does not specify the output format or explain 'unique combos' further, leaving minor ambiguity for an agent.

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

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

Schema coverage is 100% (one parameter described). The description adds context like 'local generation tracking' but does not significantly expand on the parameter meaning beyond the schema's description.

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

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

The description clearly states the resource (local generation tracking statistics) and the actions (show total runs, unique combos, breakdown by model family). It distinguishes from siblings like get_system_stats by specifying 'generation' tracking.

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 explicit guidance on when to use this tool versus alternatives (e.g., get_system_stats, get_history). While the description implies usage for generation statistics, it lacks when-not-to-use or alternative recommendations.

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 provided, so description carries full burden. It implies a read operation and specifies return of full provenance and workflow snapshot. However, it doesn't explicitly state read-only hint or any potential side effects, which is adequate but not excellent.

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 concise sentences. First sentence introduces purpose and output, second sentence provides usage context. Front-loaded with verb and resource. No waste.

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

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

For a simple tool with one parameter and no output schema, the description sufficiently covers what the tool does and when to use it. It leaves no major gaps given the low complexity.

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

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

Schema coverage is 100% with one parameter. Description adds context by mentioning the asset_id comes from 'list_assets or job completion', providing useful origin information 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?

Description clearly states the verb 'Get' and resource 'full provenance for a registered asset', specifying content (workflow snapshot) and use case (inspect parameters). This distinguishes it from sibling tools like regenerate or get_image.

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

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

Explicitly says 'Use this to inspect the parameters that generated an image before calling regenerate with overrides', giving clear context for when to use it. Does not mention when not to use or alternatives, but the 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns a merged view with per-source attribution and details the precedence logic. This is sufficient for a read-only getter tool, as there are no destructive behaviors to disclose.

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 with no fluff. The first sentence states the purpose, and the second adds important precedence details. Each 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?

For a simple tool with no parameters and no output schema, the description is reasonably complete. It explains what is returned and the precedence rules. It could optionally mention that this complements set_defaults, but it is not necessary for basic understanding.

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

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

The input schema has zero parameters, and the description does not need to add parameter information. Baseline for zero parameters is 4.

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

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

The description clearly states it returns the merged view of generation defaults with per-source attribution. It uses a specific verb ('Return') and resource ('generation defaults'), and implicitly distinguishes from sibling tools like set_defaults.

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

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

The description explains the precedence order and notes that per-call MCP tool args always win over defaults, providing context for when the defaults are relevant. However, it does not explicitly state when not to use this tool or mention alternatives beyond the implicit relationship to set_defaults.

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 bears full responsibility. It describes the action as listing, implying read-only behavior, but does not explicitly state side effects, auth requirements, or return format. With no output schema, more detail on output would improve transparency.

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

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

The description is brief, with two sentences that immediately convey the purpose and a practical usage example. No unnecessary words.

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

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

For a tool with no parameters and no output schema, the description covers the essential context: what the tool lists and how it can be used. Slightly more detail on return format would increase completeness, but it's adequate.

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

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

No parameters exist, so the description cannot add meaning beyond the schema. The schema coverage is 100% with zero parameters, meeting the baseline for this dimension.

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 explicitly states 'List installed textual inversion embeddings' with a clear verb and resource. It distinguishes from sibling list tools by specifying 'textual inversion embeddings' specifically.

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 usage context by explaining how embeddings are used in prompts with embedding:name syntax. Does not explicitly state when not to use or list alternatives, but the context is clear for a simple list tool.

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

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

Without annotations, the description carries the burden. It discloses return values (status, timing, cached nodes, output, error info including tracebacks). This is sufficient for a read operation; no hidden behaviors are omitted.

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: first states purpose and returns, second gives usage guidance. No redundancy, every sentence earns its place. Front-loaded with key 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 a single optional parameter, no output schema, and no annotations, the description is complete enough. It explains what the tool does, what it returns, and when to use it. Could add more about response structure but sufficient for the 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% with a clear description for the only parameter (prompt_id). The description adds usage context but does not enhance parameter semantics beyond the schema. 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 clearly states the tool gets execution history for a ComfyUI prompt, listing specific return elements (status, timing, cached nodes, output details, error info). This is a specific verb+resource with sufficient detail to distinguish from sibling tools like get_job_status or get_logs.

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

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

Explicitly says 'Use after a failed enqueue_workflow to diagnose what went wrong,' providing clear context for when to invoke. Does not list alternatives or when not to use, but the guidance is direct 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?

There are no annotations, so the description carries the full burden. It mentions working with remote instances and not requiring COMFYUI_PATH. But it does not disclose error behavior (e.g., file not found), authentication needs, or rate limits. This is adequate but not thorough.

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 concise sentences with no fluff. Every sentence adds value: the first states the action and output, the second provides usage context and dependency 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?

No output schema, so description should clarify the return format. It says 'return it as an inline image' but does not specify the encoding (e.g., base64) or structure. It also lacks differentiation from sibling tools like 'view_image', given the large sibling list.

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 baseline is 3. The description adds minimal value beyond the schema, only referencing the 'filename' parameter indirectly. It does not explain the other parameters or their nuances.

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

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

The description clearly states it fetches a generated image from ComfyUI and returns it inline. The verb 'Fetch' and resource 'generated image' are specific. However, it does not explicitly distinguish from sibling tools like 'view_image' or 'list_output_images'.

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 key dependency: 'Use get_history first to obtain the filename.' This helps the agent understand the workflow. However, it does not discuss when not to use this tool or alternatives.

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

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

With no annotations, the description carries the full burden. It correctly implies a read operation, but does not disclose potential errors, rate limits, or whether it is idempotent. Basic transparency is provided but not comprehensive.

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

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

The description is a single sentence of 11 words, no filler, and immediately states purpose. Excellent conciseness with 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?

The tool is simple with one parameter, but no output schema exists and the description does not explain what the status response includes. For a status-checking tool, knowing possible return values (e.g., pending, completed, failed) is important. The description is adequate but incomplete.

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 description is not expected to add much. It does not repeat the param description but provides context that the prompt ID comes from 'enqueue_workflow'. This adds mild value, meeting the baseline for high coverage.

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

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

The description uses a clear verb ('Check') and specifies the resource ('execution status of a ComfyUI prompt/job'). It mentions the key input ('by its ID'), which distinguishes it from siblings like 'enqueue_workflow' and 'cancel_job'.

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 after enqueuing a workflow, but does not explicitly state when to use it versus alternatives, nor does it provide prerequisites or exclusions. No guidance on when not to use.

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 implies a read operation ('Get') but does not explicitly confirm non-destructiveness or disclose any side effects. It also does not mention log persistence, truncation, or ordering beyond what is in the schema.

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

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

The description is concise with two sentences, front-loading the purpose and use cases. Every word adds value, no redundancy.

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

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

For a simple tool with 2 optional parameters and no output schema, the description is adequate but lacks details about return format (e.g., order, whether full logs or recent lines). It mentions specific debugging scenarios, which adds context, but could be more 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 the parameters are already well-documented in the input schema. The tool description does not add additional semantic meaning beyond what the schema provides, 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 clearly states the tool retrieves ComfyUI server runtime logs, with specific use cases like debugging errors and model loading issues. It uses a specific verb ('Get') and resource ('logs'), and is distinct from sibling tools like get_history or get_job_status.

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

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

The description provides examples of when to use (debugging execution errors, model loading issues) but does not explicitly state when not to use or contrast with alternative tools. Given siblings like get_job_status and get_history, guidance on differentiation is missing.

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 the full burden. It reveals the tool is a query (read-only) operation by mentioning 'Query' and states the return format. However, it does not explicitly state that there are no side effects, no state modifications, or potential error conditions, leaving some 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?

The description is extremely concise at two sentences. Every word is purposeful: the first sentence states the core action and return value, the second explains the optional filter. No redundant or extraneous text.

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

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

Given no output schema, the description adequately summarizes that the tool returns node inputs, outputs, and descriptions. It could mention error handling or endpoint availability, but for a simple read-only query, it is sufficiently complete for an agent to understand the tool's purpose and output.

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

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

The input schema has 100% descriptive coverage for the single parameter, and the description merely echoes the schema's substring match explanation. It adds no new semantic meaning beyond what the schema already provides, so baseline score 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 clearly states the tool queries ComfyUI's /object_info endpoint to get node type definitions, specifies optional filtering, and mentions the return type (node inputs, outputs, descriptions). The verb 'Query' and resource 'node type definitions' are specific and distinct from sibling tools like 'get_node_pack_details'.

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

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

The description explains the optional filter parameter but provides no guidance on when to use this tool versus alternatives, such as 'get_node_pack_details' or other info tools. It lacks explicit 'when to use' or 'when not to use' context.

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

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

With no annotations provided, the description bears the full burden of behavioral disclosure. It does not state whether the operation is read-only, requires authentication, has rate limits, or what errors may occur. The phrase 'from the Registry' hints at a network call but lacks sufficient detail for an agent to anticipate 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 a single concise sentence. It is front-loaded with the action and resource, and every word contributes meaning. No extraneous information is present.

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

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

Given the lack of output schema and annotations, the description is incomplete. It does not explain what 'detailed information' entails (e.g., attributes of the node pack), error responses, or pagination. An agent cannot fully understand the tool's behavior or output from this description alone.

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

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

The input schema covers the single parameter 'id' with a description and example. Since schema description coverage is 100%, the description adds no extra semantics. The tool description's mention of 'specific ComfyUI custom node pack' aligns with the parameter but does not elaborate on format or constraints beyond what the schema already 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 clearly states the action ('get detailed information'), the resource ('ComfyUI custom node pack'), and the source ('from the Registry'). It distinguishes itself from sibling tools like 'get_node_info' (which likely targets individual nodes) and 'search_custom_nodes' (which is for searching, not fetching details).

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

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

The description provides no guidance on when to use this tool versus alternatives. For example, it does not indicate whether to first search for node packs using 'search_custom_nodes' or whether this tool complements 'get_node_info'. No when-not-to-use or prerequisite information is included.

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 provided. Description reveals that the tool returns running and pending jobs, but does not disclose performance implications, authentication needs, or rate limits. Minimal additional context beyond 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?

Single sentence, no wasted words. Front-loaded with the action and resource.

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

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

Given the tool is simple with no parameters or output schema, the description adequately explains what is returned. No further detail is necessary for an agent to use 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?

No parameters exist, so schema coverage is 100%. Description adds that it retrieves the 'current' queue, which is marginally helpful. Baseline for 0 parameters is 4.

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

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

The description clearly states the tool gets the current ComfyUI execution queue, specifying it shows running and pending jobs. This distinguishes it from sibling tools that modify the 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 description implies usage is for viewing the queue state, but lacks explicit guidance on when to use this vs alternatives like cancel_job or clear_queue. It is clear from context but could be more direct.

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 correctly conveys read-only behavior and lists returned information. It could mention any required permissions or rate limits, but for a simple info tool, it is sufficient.

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

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

A single sentence that is perfectly concise, front-loading the action and listing key items with no redundant words.

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

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

For a simple tool with no parameters and no output schema, the description is complete enough. It could mention that the output is a JSON object, but the listed items provide adequate 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?

No parameters exist, and schema coverage is 100%. The description adds value by enumerating what information is included, compensating for the lack of 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 explicitly states the tool retrieves system information and lists specific components (GPU, VRAM, Python version, OS details), making the purpose clear and distinguishing it from all sibling tools.

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

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

No explicit when-to-use or alternatives guidance is provided, but given the tool's simplicity and lack of similar sibling tools, the context is clear and no exclusions are needed.

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 explains the output format options (ui vs api) and their implications. It discloses that the tool returns raw JSON and recommends api format. Could mention that it's a read-only operation, but the context makes it 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?

Two sentences, front-loaded with purpose, then usage guidance. No wasted words. Well-structured and efficient.

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 output schema and no annotations, the description covers purpose, usage context, parameter details, and alternative tools. It is complete for a read operation with two parameters.

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

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

Schema coverage is 100%, and description adds significant meaning beyond the schema: explains format parameter with usage details, and for filename suggests using list_workflows to discover available files. Adds high value.

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

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

The description clearly states 'Load a saved workflow and return its raw JSON' with specific verb and resource. It also distinguishes from sibling analyze_workflow, achieving high clarity.

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

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

Explicitly says when to use get_workflow vs analyze_workflow, providing specific scenarios where this tool is needed (for enqueue_workflow, modify_workflow, save_workflow). No exclusions needed.

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 registry is in-memory, clears on restart, and records expire after a configurable TTL, which is good behavioral context. It does not explicitly state that the tool is read-only, but 'list' implies no side effects.

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

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

Three concise sentences that front-load the core purpose and then add necessary context about registration and expiration. Every sentence adds value with no redundancy.

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

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

The description lacks details about the return format or fields of assets, and there is no output schema. While the tool is simple, the description could be more complete by indicating what properties each asset includes.

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 parameters are already well-documented in the schema. The description does not add additional meaning beyond what the schema provides; it only gives broader registry context. 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 clearly states the verb 'List' and the resource 'recently generated assets from the in-memory registry' with sorting order 'newest-first'. It distinguishes from siblings like 'list_output_images' by specifying the registry context.

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

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

The description explains when assets are registered (workflow completion) and their ephemeral nature (TTL and server restart), giving context for usage. However, it does not explicitly state when not to use this tool or name alternatives, though the context implies it for completed workflow assets.

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?

Despite no annotations, the description is adequate for a simple read operation. It does not mention return format or potential limitations (e.g., scanning subdirectories), but the behavior is straightforward.

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?

Single sentence with clear subject, verb, and object. No unnecessary words. Properly 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?

Given the tool's simplicity (one optional enum parameter, no output schema), the description is fully complete. It covers all necessary aspects for correct usage.

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

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

Schema coverage is 100% and the schema already describes the parameter's purpose and default behavior. The description adds no additional semantic value beyond what is in the schema.

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

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

The description clearly states the verb 'List', the resource 'model files', and the location 'local ComfyUI models directory'. It effectively distinguishes from sibling tools like search_models and download_model.

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

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

No guidance is given on when to use this tool versus alternatives (e.g., search_models for remote models). There is no mention of prerequisites or scenarios where this tool is appropriate.

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

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

With no annotations, the description carries full burden. It discloses the output sorting order and the environment requirement. While it doesn't cover edge cases or error states, it adequately informs the agent of the tool's basic behavior for a simple read operation.

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

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

Three sentences with no wasted words. The main action is front-loaded, return format is second, and usage guidance with alternatives is in the third. 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?

Given the tool's simplicity (2 non-required params, no output schema), the description is fully complete. It covers purpose, output, prerequisite, and alternative tools for a different context. Handles the sibling tool landscape well.

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?

Both parameters have schema descriptions (100% coverage), so baseline is 3. The description adds value by stating the default behavior ('newest-first' sort order) and clarifying the pattern matching as 'case-insensitive substring match', which goes 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 clearly states the action ('list recently generated images'), specifies the resource ('ComfyUI's output directory'), and distinguishes the behavior ('returns filenames sorted newest-first'), which differentiates it from sibling tools like get_image or view_image.

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

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

Explicitly states the prerequisite ('Requires COMFYUI_PATH') and provides clear guidance for remote ComfyUI scenarios, directing the agent to use get_history and get_image instead. This effectively tells when and when not to use the tool, with alternatives named.

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 provided; description only restates action without detailing side effects, permissions, or output nature, providing minimal behavioral insight.

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?

Single sentence, 9 words, front-loaded with no superfluous content.

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

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

Sufficient for a simple list tool with no parameters or output schema; slightly more context about scope (user library vs system) would improve completeness.

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?

No parameters exist, so description needs no additional meaning; baseline score of 4 is appropriate for zero-parameter tools.

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

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

Description uses specific verb 'list' and resource 'saved workflows from the ComfyUI user library', clearly distinguishing from sibling tools like get_workflow or create_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?

No explicit guidance on when to use or alternatives; usage is implied as a basic list operation but lacks contextual direction among many 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?

Discloses parsing, resolution using /object_info schemas, filling defaults, and returning executable workflow. However, it lacks information on error handling, unsupported Mermaid features, or validation, which is notable without annotations.

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

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

Three sentences, front-loaded with primary purpose, no unnecessary words. Each sentence adds essential information about the conversion process.

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

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

For a single-parameter tool with no output schema, the description covers input format, processing steps, and output. It could mention supported Mermaid syntax details or limitations, but overall adequate.

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

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

The description adds significant meaning beyond the schema's explanation: it specifies Mermaid flowchart text, optional code fences, node labels with class_type names, and connection labels with data types. With 100% schema coverage, this is valuable context.

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 explicitly states the tool converts Mermaid flowchart diagrams to ComfyUI workflow JSON, specifying input format and output. It distinguishes from sibling tools like workflow_to_dsl and visualize_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?

Describes the use case clearly: converting Mermaid text to a ComfyUI workflow. It details parsing steps but doesn't explicitly state when not to use or provide alternatives, though sibling context implies differentiation.

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 provided, so the description carries the full burden. It states the return value (modified workflow JSON and new node IDs), but lacks details on side effects, validation behavior, error handling, permissions, or reversibility of operations.

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

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

The description is two concise sentences. The first states the primary purpose, and the second lists the supported operations and return value. No unnecessary words.

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

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

Given the tool's complexity (multiple operation types, array of operations), the description covers the basic purpose and return value but omits ordering constraints, validation, error cases, and does not leverage an output schema. It is adequate but not 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 coverage is 100%, so baseline is 3. The description lists operation types but does not elaborate on parameter semantics beyond what the schema provides. It adds minimal additional meaning.

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

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

The description clearly states the tool applies modification operations to an existing ComfyUI workflow, lists five specific operations (set_input, add_node, remove_node, connect, insert_between), and distinguishes it from sibling tools like create_workflow or validate_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 implies usage when modifying a workflow, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The list of supported operations gives some context for selection but no comparative 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?

Without annotations, the description fully discloses behavioral traits: seeds are re-randomized by default unless explicitly overridden, and overrides apply to any matching node input. No contradictions.

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, front-loaded with the main action, and every sentence adds essential detail. 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?

Given the tool's moderate complexity with 3 parameters and no output schema, the description is sufficiently complete. It covers behavior and parameter semantics, though a note about return value (e.g., job ID) would be slightly helpful.

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%, giving a baseline of 3. The description adds value by explaining the overrides map with common keys and the disable_random_seed behavior, which supplements 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 clearly states the tool re-enqueues the workflow for an existing asset with optional overrides. It specifies the verb 're-enqueue' and resource 'workflow', and the examples of override keys distinguish it from similar tools like 'enqueue_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 explains when to use the tool for regenerating assets with optional overrides. It provides clear context but does not explicitly mention when not to use it or compare with alternatives like 'generate_image'.

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 full burden and excellently discloses the entire lifecycle: stopping the process, capturing config, freeing the port, relaunching with identical arguments, and waiting for API readiness. No contradictions.

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 efficiently conveys the entire workflow without wasted words. Every clause adds essential detail.

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

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

Given zero parameters and no output schema, the description fully explains what the tool does. It covers the entire restart sequence, making it complete for this simple operation.

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

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

The tool has zero parameters, so baseline is 4. No additional parameter information needed.

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

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

The description clearly specifies the action 'Restart ComfyUI' and details the entire process: stopping, capturing config, waiting for port, relaunching with same args, waiting for API. This distinguishes it from siblings like start_comfyui and stop_comfyui.

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

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

Usage context is implied but not explicit. The description states what the tool does but does not provide guidance on when to use it versus alternatives like start_comfyui or stop_comfyui, nor does it mention prerequisites or postconditions.

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 present, so the description carries the full burden. It mentions that the file will overwrite if it already exists, which is a key behavioral trait. However, it does not disclose other important behaviors like authentication requirements, validation, size limits, or error outcomes.

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, front-loaded with the primary purpose, and contains no fluff. Every sentence adds value.

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

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

For a simple 2-parameter tool with full schema coverage, the description adequately explains the destination, format acceptance, and overwrite behavior. It lacks mention of return values or success indicators, but the absence of an output schema reduces the need. Overall, it is fairly complete.

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

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

The input schema covers both parameters with descriptions. The main description reinforces that the workflow accepts API or UI format. No additional semantic details beyond the schema are provided, so 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 clearly states the tool saves a workflow to the ComfyUI user library and mentions it accepts API or UI format JSON. The verb 'save' and resource 'workflow' are explicit. However, it doesn't distinguish from sibling tools like create_workflow or modify_workflow, which may have overlapping functionality.

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 use this tool versus alternatives such as create_workflow or modify_workflow. No when-not-to-use or context is provided, leaving the agent without decision support.

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 present, so description carries full burden. It only states the basic action. No disclosure of pagination behavior, auth needs, rate limits, or result format beyond what schema provides.

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, no wasted words. Efficiently conveys the purpose.

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

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

For a simple search tool with no output schema, the description is adequate but could mention that results include node packs or provide usage 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 baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions.

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

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

The description clearly states the verb 'Search', the resource 'ComfyUI Registry for custom node packs', and the input 'by keyword'. It is concise and distinct from siblings like 'search_models'.

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

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

No guidance on when to use this tool versus alternatives, nor when not to use it. No mention of alternatives like 'search_models' or prerequisites.

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 provided, and description does not disclose search behavior (e.g., exact match vs fuzzy, return format, pagination, error handling). Minimal transparency for a 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?

Single sentence that is front-loaded and efficient, with no wasted words.

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

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

No output schema, and description omits return format or what the search results contain. Incomplete for a search tool that returns a list of models.

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 covers 100% of parameters with descriptions. Description adds no additional meaning beyond schema, 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?

Clearly states action (Search), resource (HuggingFace models), and scope (compatible with ComfyUI, with examples like checkpoints, LoRAs, VAEs). Distinguishes from siblings like list_local_models and download_model.

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?

Implicitly indicates when to use (searching for remote models), but lacks explicit when-not-to-use or alternatives. No mention of prerequisites or context.

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

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

With no annotations, the description details the dual behavior: in-memory (lost on restart) vs. persistent to config file. It mentions the config file path, adding transparency about side effects.

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

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

Two sentences with no redundant words. The first sentence states the action, the second explains the optional behavior and use case. Efficient and front-loaded.

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

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

For a simple mutation tool with well-documented parameters, the description covers purpose, behavior modes, and practical usage. No output schema is needed as the return is likely a status.

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. The description adds value by explaining the values map contains typical defaults (width, steps) and clarifies the persist parameter's effect beyond the schema's minimal description.

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

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

The description clearly states 'Update generation defaults' and lists example values like width, height, steps. It distinguishes from sibling tools like get_defaults by implying it modifies rather than retrieves.

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

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

The description explicitly advises 'Use this to avoid repeating common values', providing a clear use case. It also explains the persist parameter but does not explicitly exclude scenarios.

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 provides key behavior: uses saved info, supports two install types, and waits up to 60s for API readiness. It doesn't cover error handling or permission requirements, but is largely transparent for its scope.

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, no superfluous words. Front-loaded with the core purpose, followed by support details and a key behavioral note (60s wait). Highly efficient.

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 parameters, no output schema, and no annotations, the description covers the essential usage and behavior. It could mention failure modes or prerequisites, but remains adequate for a tool with a simple interface.

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 and 100% schema coverage, so the baseline is 4. The description doesn't add parameter info but explains the tool's reliance on saved process info, which contextualizes the param-less input.

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

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

The description clearly specifies that the tool starts ComfyUI using saved process info, supports two installation types, and waits for API readiness. It effectively distinguishes from siblings like stop_comfyui and restart_comfyui.

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

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

It indicates usage after a stop_comfyui call by mentioning 'process info saved from a previous stop_comfyui call.' It lacks explicit when-not-to-use or alternatives, but the context implies it's for resuming, not initial launch.

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?

Despite no annotations, the description fully discloses destructive behavior (kills process tree) and side effects (resets WebSocket client), which is critical for a stop command.

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 efficient sentences with no wasted words. The first sentence states the core purpose, followed by important details about process capture and effects.

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 tool, the description is fully adequate. It explains the action, its consequences, and its relationship to sibling tools without needing additional details.

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?

No parameters exist, so schema coverage is 100%. The description adds context about the operation's purpose without needing parameter details.

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

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

The description clearly states the action (stop) and the resource (running ComfyUI process). It distinguishes from siblings like start_comfyui and restart_comfyui by mentioning process info capture for restart.

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 before start_comfyui by mentioning restart capability. However, it does not explicitly contrast with restart_comfyui or explain 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?

No annotations are provided, so the description must disclose behavioral traits. It indicates the tool suggests settings based on history but does not mention if it is read-only, side effects, or behavior when no history exists. Adequate but minimal.

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

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

Two sentences, front-loaded with the core purpose, and no extraneous information. Every sentence serves a clear function.

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 is provided, yet the description does not explain the format or structure of the returned suggestions. It adequately covers the input parameters but lacks completeness regarding the output, which is essential for an agent 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?

Schema coverage is 100% with descriptions, so baseline is 3. The description adds value by grouping query methods (model_family, lora_hash, search, limit) and explaining their purpose beyond the schema, earning a 4.

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

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

The description clearly states it suggests sampler/scheduler/steps/CFG settings based on local generation history, and specifies query methods by model family, LoRA hash, or text search. This distinguishes it from sibling tools like generation_stats or get_history.

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 context (when you need proven settings from history) but does not explicitly state when not to use or provide alternatives among siblings. It is clear enough for an AI agent to infer appropriate use.

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?

Discloses dual upload strategy (HTTP first, filesystem fallback) and the condition (COMFYUI_PATH set). No annotations provided, so description carries full burden. Missing details like overwrite behavior or supported formats but sufficient for basic usage.

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

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

Two sentences, front-loaded with purpose, then implementation detail. No fluff, though could be slightly restructured 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?

Given no output schema and simplicity of upload, description covers main purpose and fallback. Could mention file size/type constraints but adequate for selection and invocation.

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

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

Schema coverage is 100%, but description adds value: explains auto-detection of filename and that source_path is absolute. Also provides context on the upload mechanism beyond 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?

Clear verb ('Upload') and resource ('local image file to ComfyUI's input/ directory'), with specific purpose ('referenced in LoadImage nodes'). Distinguishes from siblings like download_model or get_image.

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?

Description mentions fallback behavior but lacks explicit when-to-use or when-not-to-use guidance. No alternatives for uploading images are discussed.

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 description must disclose behavior. It clearly states the tool does not execute the workflow (non-destructive), and returns a list of errors and warnings. This adequately covers the most important behavioral traits for a validation 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?

Two sentences: first sentence states purpose and key constraint (without execution), second lists checks and return type. No wasted words, front-loaded with 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 the tool's simplicity (one parameter, no output schema, no annotations), the description is complete. It explains input format, behavior, checks performed, and output format. No 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 coverage is 100%; the description of the parameter in the schema already explains what 'workflow' is. The tool description adds no additional meaning beyond stating it accepts a JSON string or object, which is already 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?

Description clearly states 'validate a ComfyUI workflow without executing it' and lists specific checks (missing node types, broken connections, etc.). It distinguishes from sibling execution tools by emphasizing non-execution. The purpose 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?

Implies usage before execution via 'without executing it', but lacks explicit guidance on when to use this tool versus alternatives like 'analyze_workflow'. No when-not or alternative recommendations are provided.

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

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

With no annotations, the description bears full burden. It discloses that only image mime types (PNG/JPEG/WebP) are supported, and directs audio/video to get_image. However, it does not mention error handling, size limits, or any side effects. Since the tool is read-only by design, this is reasonably transparent, but lacks full behavioral detail.

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

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

Three sentences, front-loaded with the main action, no redundant words. Every sentence adds value: action, usage context, constraints, and alternatives. Highly efficient.

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 single-parameter tool with no output schema, the description covers purpose, usage timing, and constraints. It provides a sibling tool alternative. However, it does not explain the output format (e.g., base64 vs rendered) or error cases, which could be gaps for an agent.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds slight context by mentioning that asset_id comes from job completion, but does not add new semantic meaning beyond the schema. The description does not elaborate on the parameter format or constraints beyond what the schema already 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 clearly states the action (fetch and return inline image), the resource (registered asset), and the output format (inline image for agent to see). It distinguishes from sibling get_image by specifying that view_image only supports image mime types and provides inline display, while get_image is for audio/video assets to disk.

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

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

Explicitly says 'Use this after enqueue_workflow completes' and provides context that asset_id is in the completion notification. Also specifies when not to use: for audio/video assets, which should use get_image. This gives clear when-to-use and when-not-to-use 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?

Without annotations, the description carries the full burden. It discloses that the tool converts JSON to Mermaid syntax with category grouping and data type labeling, which is sufficiently transparent for a read-only conversion tool. No side effects or destructive actions are mentioned, which is appropriate.

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

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

The description is a single, well-structured sentence that front-loads the main action and includes key details without extraneous words. Every part 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?

Given 3 parameters with full schema coverage, no output schema, and no annotations, the description adequately covers the tool's function and output. It could mention that the return value is a string, but the Mermaid syntax mention is sufficiently complete for an agent to understand the result.

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 each parameter is already documented. The description adds value by explaining the output structure (grouped nodes, labeled connections) but does not add specific semantics to individual parameters beyond what the schema provides. 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 clearly states the tool converts ComfyUI workflow JSON to a Mermaid flowchart, with specifics about grouping and labeling. It distinguishes itself from the sibling tool 'visualize_workflow_hierarchical' by implying a different visualization approach.

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

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

The description explains what the tool does but does not explicitly guide when to use this tool versus alternatives like 'visualize_workflow_hierarchical' or other visualization siblings. Usage context is implied but 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?

No annotations are provided, so the description carries full burden. It discloses behavioral traits like detecting logical sections, resolving Get/Set virtual wires, and producing different views. However, it does not mention side effects or permissions, though for a visualization tool these are minimal.

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 concise sentences: first states purpose, second explains features, third provides usage advice. No redundant words, front-loaded with key 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 5 parameters and no output schema, the description covers the major aspects: purpose, usage context, and parameter roles. It mentions output types (overview, detail, list, summary) but could be more explicit about return format for each view, though the 'view' parameter descriptions help.

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% (baseline 3), and the description adds significant context: it explains each view type in detail (e.g., 'compact diagram with sections as summary nodes'), clarifies that 'section' is required when view=detail, and mentions defaults for 'direction' and 'show_values'.

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

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

The description clearly states 'Visualize a large ComfyUI workflow as a hierarchical diagram' with specific features like detecting logical sections and resolving virtual wires. It distinguishes itself from siblings like 'visualize_workflow' by focusing on large workflows (20+ nodes) and hierarchical structure.

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

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

The description says 'Best for workflows with 20+ nodes,' providing clear usage context. Though it does not explicitly name alternatives, the sibling list includes 'visualize_workflow' which likely serves smaller workflows, implying when not to use this tool.

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

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

Without annotations, the description carries the full burden. It explains what is extracted (full workflow API format and prompt data from tEXt chunks) but does not cover error cases, file requirements, or permission needs. A reasonable disclosure for a simple extraction tool.

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