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

Annotations already mark it as read-only and idempotent, and the description adds substantial context: raw dict return shape, best-effort display-name enrichment via /object_info with a documented fallback, and the prompt_nodes detection limitation. This goes well beyond the annotation baseline.

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?

Structured with clear Description/Args/Returns sections and bullet-list return keys. Although lengthy, every sentence contributes distinct, useful information and the formatting keeps it scannable.

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

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

Despite having an output schema, the description still documents every return key with types and examples, plus graceful fallback behavior. For a single-parameter read-only tool, this is fully complete.

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

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

With schema description coverage at 0%, the description fully compensates by explaining that workflow is a JSON string keyed by node ID with class_type and inputs. This gives the agent the exact format needed, which the schema alone does not.

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

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

States 'Analyze a ComfyUI workflow and return its structured shape' — a specific verb plus resource. It also distinguishes itself from comfyui_summarize_workflow, making the tool's unique role immediately clear.

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

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

Explicitly instructs to use this tool instead of comfyui_summarize_workflow when a raw dict is needed without parsing prose. This provides a clear alternative and a concrete when-to-use criterion.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not restate safety. It adds value by disclosing what is scanned for (arbitrary code, shell commands, file system access) and the return structure (dictionary with counts and lists), which are behavioral details beyond the annotations.

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

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

The description is three sentences, front-loaded with the core purpose, then expands on scope, use case, and return value. It is concise with no wasted words, and the 'Returns:' section clearly separates output info.

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, strong safety annotations, and an output schema, the description fully covers the tool's behavior. It explains what it does, why you'd use it, what it looks for, and what it returns. No critical information is missing.

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

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

The input schema has zero properties, so there are no parameters to describe. The description correctly omits parameter details. With 0 params, a baseline of 4 is appropriate, and the description does not need to compensate for any schema gaps.

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 first line states 'Audit all installed nodes to identify potentially dangerous ones' with a specific verb ('audit') and resource ('all installed nodes'), clearly distinguishing this from sibling tools like list_nodes or get_node_info. The description further elaborates on the scanning criteria, making the purpose unambiguous.

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

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

The description provides a clear use case ('Useful for building a dangerous node blacklist') and describes the scan focus (code execution, shell commands, file system access). It does not explicitly mention alternatives or when not to use, but the context is sufficient for an AI agent to infer when this tool is appropriate.

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

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

Annotations already signal destructive behavior (destructiveHint=true), and the description adds the phrase 'and remove,' clarifying that the task is deleted. However, it doesn't disclose side effects like whether partial downloads are deleted or if the action is irreversible, so it adds only marginal context beyond annotations.

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

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

The description is concise and front-loaded with the action, but the docstring format is rather minimal. It earns its place without verbose explanations, though it could be slightly more structured with clearer separation of purpose and parameters.

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

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

For a simple tool with one parameter and an output schema, the description is adequate but lacks guidance on when to use it and what happens to the underlying download files. It doesn't address edge cases like canceling a completed or already-canceled task, making it only minimally 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 0%, but the description provides a clear docstring for task_id, stating it is the ID of the download task to cancel. This adds meaningful context over the schema's bare 'Task Id' label, though it could be even more explicit about where to find this ID.

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 ('Cancel') and the resource ('model download task'), and uses the verb 'remove' to add specificity. It distinguishes itself from sibling tools like comfyui_cancel_job, which targets jobs rather than download tasks.

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 canceling model downloads but does not explicitly mention when to use it instead of alternatives like comfyui_cancel_job. There is no exclusions or comparison, so the guidance is implied rather than explicit.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is disclosed. The description adds the scope (running or queued jobs) but does not explain what happens to partial outputs or whether canceling an already-finished job is a no-op. Since annotations provide the core safety profile, the description offers only marginal additional behavioral context, earning a 3.

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, focused sentence with no unnecessary words. It front-loads the action ('Cancel') and immediately specifies the resource and target parameter, making it highly efficient and easy to parse.

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

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

For a simple single-parameter tool, the description is largely complete: it states the action, the resource, and the targeting mechanism. With annotations covering destructive behavior and idempotency, and an output schema present, the remaining gaps are minor—missing guidance on alternatives and error handling when the job doesn't exist. Given the tool's simplicity, this is very close to fully sufficient.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that prompt_id is the identifier of the job to cancel, which adds meaning beyond the schema's bare type declaration. However, it does not explain how to obtain a prompt_id or what formats are valid, leaving some ambiguity for a parameter central to the operation.

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

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

The description uses the specific verb 'Cancel' with the resource 'job' and the targeting mechanism 'by its prompt_id'. This clearly distinguishes the tool from siblings like comfyui_interrupt (which stops the running job) and comfyui_clear_queue (which clears the entire queue), making its unique role obvious.

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

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

The description implies usage when you have a prompt_id and want to cancel that specific job, but it does not explicitly state when to prefer this tool over alternatives like comfyui_interrupt or comfyui_clear_queue. No exclusions or alternative recommendations are provided, leaving the guidance at an implied level.

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

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

The description discloses important behavioral details beyond the annotations, such as 'Stop the currently running workflow' for clear_running and 'Remove pending workflows' for clear_pending. This adds context about the destructive nature and the distinction between flags. It aligns with the destructiveHint and idempotentHint annotations, with no contradiction.

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

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

The description is concise and well-structured. It starts with a clear one-line summary, then provides a brief Args block. Every sentence is meaningful, and the formatting is clean, making it easy for an agent to parse.

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

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

For a destructive queue-clearing tool, the description covers the core behavior and parameter effects. The presence of annotations (destructiveHint, idempotentHint) and an output schema reduces the burden on the description. It could mention return behavior or edge cases, but it is reasonably 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?

The schema has no descriptions for the parameters, but the description adds explicit semantics for both clear_running and clear_pending, explaining what each flag does. This is valuable beyond the schema's type and title information, making the tool's behavior clearer.

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: 'Clear items from the execution queue.' This is a specific verb+resource combination that distinguishes it from sibling tools like get_queue or run_workflow. However, it does not explicitly differentiate from close siblings such as comfyui_interrupt or comfyui_cancel_job, which might also affect queue/running workflows.

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 explicit guidance on when to use this tool versus alternatives like comfyui_cancel_job or comfyui_interrupt. There is no mention of prerequisites, suitable contexts, or exclusions. The usage is only implied by the tool's name and description.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context about parameter overrides and default behavior ('Pass either "" or "{}" for no overrides'), but it does not explicitly state that the workflow is not executed, which would further clarify side effects.

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

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

The description is well-organized with a clear purpose statement, a bulleted list of templates, an Args section, and a usage example. Every element adds value, and the structure makes it easy to scan and understand.

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 complexity of the tool (multiple templates and JSON parameters), the description is highly complete. It covers all necessary inputs, defaults, constraints, and provides an example. The presence of an output schema means return values do not need to be explained in the description.

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

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

Schema description coverage is 0%, yet the description fully compensates. It lists all valid template names, explains that params is a JSON string, documents common keys, provides default behavior, and gives a concrete example. This is exemplary parameter documentation.

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

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

The description begins with a specific verb+resource: 'Create a ComfyUI workflow from a template with optional parameter overrides.' It clearly distinguishes this from sibling tools like comfyui_run_workflow and comfyui_generate_image by focusing on creation rather than execution or generation.

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

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

The description clearly communicates when to use this tool: to create a workflow from one of the listed templates. It does not explicitly mention alternatives or exclusions, but the template list and example imply that this is the right choice for workflow creation, not execution.

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

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

Annotations indicate this is not read-only and is open-world, but the description adds valuable behavioral context by stating that the tool returns a 'JSON with download task status' and that progress should be checked via another tool. This implies an asynchronous task model, which is important beyond the raw annotation flags.

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 short, front-loaded sentences. The first sentence states the core purpose and mechanism; the second explains the return value and next step. 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?

Given the output schema exists and parameter schema is fully covered, the description does not need to repeat those details. It provides enough context: what the tool does, what it returns, and how to follow up. This is complete for an agent to invoke the tool correctly.

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

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

The input schema already provides 100% coverage of parameters, so the baseline is 3. The description adds meaning by naming HuggingFace and CivitAI, which clarifies the 'allowed domain' constraint on the 'url' parameter and gives the agent a better sense of valid inputs.

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 ('Download a model'), the specific sources ('from HuggingFace or CivitAI'), and the mechanism ('via ComfyUI-Model-Manager'). This distinguishes it from sibling tools like comfyui_search_models or comfyui_get_download_tasks.

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

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

The description provides clear context for when to use the tool (to download models) and gives a direct follow-up instruction ('Use comfyui_get_download_tasks to check progress'). It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select it appropriately.

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

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

Annotations already convey that this is not read-only, is not idempotent, and is open-world. The description adds the 'default txt2img workflow' context, but it does not disclose behavioral details like asynchronous queueing or blocking behavior, which are partially covered by the 'wait' parameter.

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 that is front-loaded with the verb and resource. Every word contributes meaning, with no fluff or repetition of schema details.

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

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

For a tool with 8 parameters and an output schema, the description is minimal but adequate for the core intent. It doesn't mention important behaviors like whether jobs are queued asynchronously or return immediately, which is a notable gap given the 'wait' parameter exists.

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

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

The input schema documents all 8 parameters with clear descriptions (100% coverage), so the description does not need to elaborate. The phrase 'text prompt' reinforces the primary 'prompt' parameter, but adds no extra semantics beyond the schema.

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

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

The description states a specific action ('Generate an image') with a clear resource ('from a text prompt') and method ('using a default txt2img workflow'). It distinguishes itself from sibling tools like upscale or transform, though it doesn't explicitly contrast with comfyui_run_workflow.

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

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

Usage is implied by the description: it is for generating an image from a text prompt. However, there is no explicit guidance on when to choose this over alternatives like comfyui_run_workflow or when not to use it, so the guidance is indirect.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds return payload details (total tasks, completed, in progress, processing), which is useful but does not disclose additional behaviors like rate limits or side effects.

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

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

The description is two sentences, front-loaded with a clear action, followed by a concise return format explanation. Every word 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 low complexity (no parameters, simple status query), the description is complete enough. It explains what is returned and is consistent with annotations, though it could mention related tools or 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?

The tool has zero parameters, and the baseline for 0-parameter tools is 4. The description does not need to explain parameters, and the schema coverage is trivially 100%.

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 checks 'custom node operation queue status' with a specific verb and resource. While it is distinct from siblings like comfyui_get_queue, it does not explicitly differentiate itself.

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

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

No guidance is provided on when to use this tool versus alternatives such as comfyui_get_queue_status or comfyui_get_progress. The user must infer its use case from the name and description.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context by specifying that it returns a list of download tasks with progress, speed, and status, and clarifies that it focuses on 'active' downloads. No contradictions with annotations.

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

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

The description is concise: one sentence for purpose and a brief returns line. It is front-loaded and every sentence adds value. The docstring formatting is acceptable.

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 simple tool with no parameters, strong annotations, and the existence of an output schema, the description is sufficiently complete. It could mention when to use it relative to siblings (e.g., for monitoring downloads), but that gap is already reflected in usage_guidelines. The core behavior and return structure are covered.

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

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

The tool has zero parameters, so the baseline is 4. There are no parameter semantics to add beyond the schema, and the description correctly focuses on the return value rather than 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 states a specific verb ('check') and resource ('active model downloads'), and the return format (JSON list with progress, speed, status). This distinguishes it from sibling tools like get_queue or get_progress, which relate to workflow execution rather than download tasks.

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 provided on when to use this tool versus alternatives. With siblings like comfyui_download_model, comfyui_cancel_download, and comfyui_get_progress, the description does not explain why this tool should be preferred for checking download status or which contexts favor it.

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

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

The description goes well beyond the annotations, explaining server-side pagination, the extra entry request for has_more, and detailed edge cases for total. This reveals significant behavioral traits (such as round-trip optimization and total's conditional semantics) that are not in the annotations.

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

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

The description is well-structured with clear sections for purpose, behavior, args, and returns. It is detailed but every sentence earns its place, especially the bullet-pointed return semantics. The front-loaded first sentence immediately conveys the tool's core purpose.

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

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

Given the tool's complexity, the description is thorough: it explains pagination, return envelope keys, and all edge cases for total and has_more. The output schema exists but the description goes beyond it, making the tool fully understandable 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%, so the baseline is 3. The description only restates the parameter defaults and ranges already present in the schema, adding no new semantic meaning beyond what is already structured.

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 browses ComfyUI execution history in a read-only manner. The verb 'Browse' is specific and the resource 'execution history' is distinct from sibling tools like get_queue or get_job, making the purpose unambiguous.

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

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

While no explicit alternatives are mentioned, the description provides clear context that this tool is for read-only browsing of execution history, which distinguishes it from mutating tools. However, it does not explicitly say when not to use it or mention alternatives like get_job.

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

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

The description discloses useful behavioral details beyond annotations: it explains the return format (Base64 or URL) and the server-side re-encoding behavior when preview_format is used. Annotations already declare read-only/idempotent safety, so the additional context about response formats and thumbnail generation adds value.

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 a clear opening sentence and a brief Returns section. It is front-loaded and each sentence contributes useful information, though the docstring-style 'Returns:' block is slightly formal but not wasteful.

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 rich schema annotations and output schema, the description covers the essential behavior (download vs URL, preview re-encoding). It is sufficient for an agent to understand the tool's capabilities, though it does not detail edge cases or error conditions, which are not critical here.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds a small amount of context about the behavior of response_format='data_uri' and preview_format re-encoding, but does not significantly enhance parameter understanding 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's function with a specific verb ('Download') and resource ('a generated image from ComfyUI'), and mentions the alternative of returning a direct view URL. This distinguishes it from sibling tools like comfyui_list_outputs (which lists images) and comfyui_upload_image (which uploads).

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 retrieving or downloading generated images, but does not explicitly state when to use this tool versus alternatives (e.g., comfyui_list_outputs for browsing, comfyui_get_workflow_from_image for extracting workflows). The context is clear but there are no explicit exclusions 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?

The description goes well beyond the readOnlyHint/idempotentHint annotations by detailing the exact return structure: a unified job object with specific fields (status values, timing fields, outputs, error). It also transparently discloses the breaking change in the envelope shape, which is crucial behavioral context for callers.

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

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

The description is front-loaded with the core purpose, then logically expands into return shape, usage, and a migration note. Every sentence adds value and the structure is easy to scan. It is slightly longer than minimal but all content is necessary for a tool that replaces a previous API shape.

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 low complexity (single parameter, simple lookup), the description is complete: it explains the operation, the unified return schema (including statuses and error fields), when to use it, and an important backward-incompatibility note. The presence of an output schema further reduces the burden, but the description already covers the essential 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?

With schema_description_coverage at 0%, the description does compensate by tying the sole parameter to the lookup action ('by prompt_id'). However, it does not explain what a prompt_id is, how it is created, or its format. The reference in the return keys reinforces its role but adds no syntactic detail. Despite this gap, the single-parameter context makes the meaning reasonably clear.

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

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

The description opens with a specific verb-resource pair: 'Look up a single job by prompt_id' and further scopes it 'across queue + history.' This clearly distinguishes it from sibling tools like comfyui_list_jobs (listing) and comfyui_get_history (history envelope). The purpose is unambiguous and immediately actionable.

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

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

It states exactly when to use the tool: 'Use this to check on a job that may be queued, running, or already finished.' Additionally, the note about replacing the old /history/{prompt_id} envelope shape gives explicit migration guidance, making the when-not and alternative context clear.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. However, the description adds no additional behavioral context, such as what the metadata contains, potential errors, or rate limits. It simply restates the function name and arguments, providing no value beyond the annotations.

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

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

The description is very concise: a one-sentence purpose followed by a two-item argument list. It is front-loaded with the key verb phrase and uses a clean, structured format. Every sentence earns its place without unnecessary verbosity.

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 two string parameters, an output schema, and rich annotations, the description is mostly sufficient. It explains the purpose and parameters clearly. However, it lacks any usage context or behavioral details (e.g., what metadata fields are returned), though the output schema likely covers return values. Overall, it is complete enough for a basic metadata getter.

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

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

The schema has 0% description coverage, but the description compensates by explaining both parameters: folder is 'Model folder type (checkpoints, loras, vae, etc.)' and filename is 'Name of the model file.' The folder examples (checkpoints, loras, vae) add practical meaning beyond the raw schema, making the parameters more understandable.

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 function: 'Get metadata for a model file.' It specifies the resource (model file) and the verb (get), which is unambiguous. However, it does not explicitly differentiate this from sibling tools like comfyui_list_models or comfyui_get_model_presets, so it lacks sibling differentiation.

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, nor does it mention prerequisites or exclusions. It only lists the arguments, which implies the user needs to supply folder and filename but gives no context about the typical use case or when other tools might be more 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?

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds valuable behavioral detail: presets are baked into the MCP rather than fetched from the ComfyUI server, model_family takes precedence when both args are supplied, and the exact shape of the return value is specified. No contradiction with annotations.

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

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

The description is well-structured with a short summary, Args section, and Returns section. Every sentence adds useful information—precedence, static data source, return keys—without redundancy or filler. It is detailed but appropriately sized for the tool's complexity.

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

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

The description is complete for this tool: it covers purpose, data source, parameter semantics, edge-case precedence, and return format. Even though an output schema exists, the description's explicit return structure helps callers know exactly which keys are available.

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

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

The input schema provides no descriptions (0% coverage), so the description fully compensates by explaining each parameter, including valid family identifiers, accepted aliases, requiredness conditions, and an example filename-to-family mapping. This is far beyond baseline.

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

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

The description opens with a specific verb-object pair: 'Get recommended generation presets for a model family.' This clearly distinguishes it from sibling tools like comfyui_get_model_metadata or comfyui_get_prompting_guide by stating exactly what resource it returns and for what purpose.

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

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

The description provides clear context on when to use the tool: it returns static community presets and requires at least one of model_name or model_family, with precedence rules. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of the highest bar.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful context about the return dict and optional flags like deprecated and experimental, without contradicting any annotations.

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

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

The description is concise and well-structured: a clear front-loaded purpose sentence followed by a compact enumeration of return keys. Every sentence contributes value 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?

For a simple read-only info tool, the description fully covers the return structure and the parameter, and it is supported by strong annotations and schema. No gaps remain.

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

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

Schema coverage is 100%, and the parameter description includes an example and a pointer to list_nodes. The tool description itself adds no additional parameter semantics, so it meets the baseline for high schema 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 it retrieves input/output schema and metadata for a single ComfyUI node type, using the specific verb 'Get' and a specific resource. This distinguishes it from siblings like comfyui_list_nodes (which lists all nodes) and comfyui_get_model_metadata.

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 use for single-node lookups but does not explicitly state when to use it over alternatives. The schema hint about using comfyui_list_nodes to discover class names is helpful, but it is not part of the description text itself.

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

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

Annotations already indicate a read-only, idempotent, non-destructive operation. The description adds useful context: it returns status, queue position, and output files when available, and clarifies that step-level detail is inaccessible via this endpoint—information not captured by annotations.

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

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

The description is front-loaded with the primary action and return summary, and each sentence adds value. The Args section is slightly redundant with the schema but adds the origin detail. Overall efficient with minimal fluff.

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

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

Covers the core behavior, return contents, and the key WebSocket limitation, which is sufficient for a simple progress getter with an output schema. Could elaborate on error/unknown status meanings, but the status list is already explicit. Adequate for agent invocation.

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

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

The schema only lists 'prompt_id' as a string with zero description coverage. The description compensates by explaining that prompt_id is the one returned by run_workflow or generate_image, giving the agent crucial provenance and usage context 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 tool fetches workflow execution progress via HTTP, using a specific verb and resource. It also distinguishes itself from sibling tools by mentioning the WebSocket limitation, setting it apart from get_queue, get_history, and get_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?

Explicitly tells the agent when this tool is appropriate (basic progress via HTTP) and when to use an alternative (wait=True on run_workflow/generate_image for step progress and current node via WebSocket). This is a clear when/when-not/alternative framing.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds that the data is baked into the MCP and always returns a guide with specific keys, and advises reading result['guide'] directly, which clarifies the return behavior beyond the annotations. It does not describe error handling for invalid family identifiers, but the parameter guidance mitigates that.

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 structured with a one-sentence summary, a short explanatory paragraph, and labeled Args/Returns sections. Every sentence adds either purpose, context, or parameter guidance without fluff.

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

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

Given that this is a simple static lookup tool with one parameter, the description covers the parameter values, the static nature, and the exact return shape. It even includes a usage tip for reading the guide directly, making it sufficiently complete for an agent to invoke the tool correctly.

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

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

The input schema provides only the parameter name and title with no description or enum, so schema coverage is 0%. The description compensates by listing all valid family identifiers and accepted aliases (sd15, sdxl, flux, etc.), giving the agent actionable syntax and exact accepted 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 opens with 'Get the prompting guide for a model family,' which combines a specific verb and resource. It further clarifies that the guide is static and separate from server state, distinguishing it from sibling tools like get_model_metadata or get_server_features.

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 the context that this tool returns static data and explicitly notes that it does not reflect the connected server's installed models or state. This tells the agent when not to expect dynamic information, but it does not name alternative tools for server-specific data, so the guidance is helpful but not fully explicit.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat safety behaviors. It adds only the context 'current' to imply a point-in-time snapshot, which is a slight enrichment, but it does not disclose additional behavioral details. This is consistent with annotations, so no contradiction.

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

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

The description is a single, front-loaded sentence with no fluff. Every word earns its place, making it 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?

For a zero-parameter read-only tool, the description is largely sufficient, especially with an output schema covering return values. However, the lack of disambiguation from comfyui_get_queue_status creates a minor completeness gap, leaving the agent to guess which queue-related tool is appropriate.

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

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

With zero parameters, the schema coverage is trivially 100%, and the baseline is 4. The description adds no parameter details, but none are needed since there are no parameters to explain.

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

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

The description uses a specific verb 'Get' and identifies the resource as 'the current ComfyUI execution queue state', which clearly states what the tool does. It is not a tautology and is distinguishable from siblings like comfyui_clear_queue or comfyui_interrupt, despite potential ambiguity with comfyui_get_queue_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 no guidance on when to use this tool versus alternatives such as comfyui_get_queue_status or comfyui_get_progress. There is no mention of use cases, prerequisites, or exclusions, leaving the agent to infer appropriate usage.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds that it returns running and pending prompts but no further behavioral context such as response format or latency. Annotations carry most of the responsibility here.

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 with a clear verb-first structure. It front-loads the purpose and contains no redundant information.

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

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

Given the simplicity of the tool (no parameters, output schema present, annotations for safety), the description is sufficient. A minor gap exists in not differentiating from 'comfyui_get_queue', but the core purpose is well-covered.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. The baseline for zero-parameter tools is 4, and the description does not need to add 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?

Description uses a specific verb ('Get') and resource ('queue status') and clearly states the inclusion of running and pending prompts. However, it does not explicitly distinguish from the sibling 'comfyui_get_queue', which is likely a simpler variant.

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 provided on when to use this tool versus alternatives like 'comfyui_get_queue' or 'comfyui_get_progress'. The description simply states what the tool does without any context on selection criteria.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the raw response format ('typically a dict of {feature_name: bool}') and notes it returns the raw `/features` response without post-processing. This goes beyond the annotations by revealing the exact response shape and the 'raw' nature, which helps set expectations.

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

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

The description is compact and front-loaded: the first line states the core purpose, the second adds the return format, and a third sentence provides a directed usage example. Every sentence earns its place, with no redundancy or filler. Code formatting (`/features`, `{feature_name: bool}`, `supports_preview_metadata`) improves 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?

This is a simple zero-parameter tool with strong annotations and a clear description that fully explains the return type and provides a motivating use case. The description is complete for an agent to select and invoke the tool correctly without needing additional context. The presence of an output schema also reduces the need to document return values further.

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

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

The tool takes zero parameters, so the schema carries no parameter information and the description needs no parameter explanations. The baseline for 0 params is 4, and the description appropriately avoids inventing parameters while still mentioning the output shape and usage 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 opens with 'Get the feature flags advertised by the ComfyUI server' — a specific verb ('Get'), a clear resource ('feature flags' from the server), and it distinguishes this from sibling tools like comfyui_get_system_info by focusing on feature flags. The exact endpoint `/features` and the 'dict of {feature_name: bool}' structure further clarify the purpose.

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

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

The description explicitly frames when to use the tool: 'Useful for capability-based branching' and gives a concrete example involving `comfyui_get_image`. It does not explicitly state when not to use it or name alternative tools for exclusion, but the context is clear enough that an agent can decide appropriately.

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

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

Annotations already declare the tool as read-only and idempotent, so the bar is lower. The description adds important behavioral context by explaining that the information is sanitized and whitelist-filtered, with sensitive fields deliberately excluded. This goes beyond the annotations and helps the agent understand privacy and safety aspects.

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

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

The description is concise and well-structured: it opens with the main purpose, specifies the relevant system stats, and explains excluded sensitive fields. The Returns section is clearly formatted. Every sentence contributes useful information without redundancy.

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

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

Given the tool's simplicity (no parameters), the description is complete. It explains both what is returned and what is deliberately excluded, providing adequate context for an agent to decide to call it. The output schema likely details the return types, so the description does not need to elaborate further.

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

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

The tool has zero parameters, so the baseline is 4. The description adds value by describing the return structure (keys like comfyui_version, devices, queue), which indirectly clarifies what the caller can expect, even though parameter semantics are not applicable.

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

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

The description clearly states the tool returns sanitized ComfyUI system information, with a specific verb and resource. It details what is included (GPU VRAM, queue depth, ComfyUI version) and excluded (sensitive fields), which distinguishes it from siblings like comfyui_get_queue_status and comfyui_get_server_features, though it does not explicitly name alternatives.

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

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

The description provides clear usage context: it is 'useful for making generation decisions'. It does not explicitly state when not to use it or name alternatives, but the context is sufficient to infer appropriate use cases. No exclusions are mentioned.

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

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

Annotations already cover read-only and non-destructive behavior. The description adds value by explaining the underlying mechanism ('ComfyUI embeds the full workflow JSON and prompt data in PNG text chunks') and detailing return values (workflow/prompt parsed JSON or None, plus a message). This goes beyond the annotation hints, though it does not discuss error handling or edge cases.

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

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

The description is well-structured with a summary paragraph, a short explanation of why, and a clean Args/Returns layout. Every sentence contributes necessary detail; there is no redundancy or filler.

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

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

Given the tool's simplicity and the presence of output schema plus annotations, the description is complete. It explains the parameters, return shape, and purpose. No critical information is missing for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 0%, but the Args section provides meaningful definitions: filename is 'Name of the PNG file to extract metadata from', and subfolder is 'Subfolder within ComfyUI's output directory (default: empty)'. This fully compensates for the missing schema descriptions and clarifies the expected path semantics.

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

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

The description opens with 'Extract embedded workflow and prompt metadata from a ComfyUI-generated PNG', which is a specific verb and resource. It clearly differentiates from siblings like comfyui_get_model_metadata and comfyui_get_image by focusing on embedded workflow extraction. The phrase 'for inspection or re-execution' further clarifies why this tool exists.

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

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

The description provides a clear context: 'This enables extracting the exact settings used to generate an image for inspection or re-execution.' This implies when to use the tool but does not explicitly mention alternatives or when-not-to-use conditions. Because alternatives are not named, it falls short of a 5.

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

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

The description adds the useful precondition about prior uploads and clarifies mask semantics. However, it does not disclose asynchronous behavior or output handling beyond what the 'wait' parameter already describes. Annotations include readOnlyHint=false and destructiveHint=false, and the description does not contradict these, so the additional behavioral context is moderate.

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

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

The description is short and front-loaded with the main action. The three sentences are efficient, though the mask white-region note slightly duplicates the schema's parameter description. Overall, it is concise and structured logically: purpose, prerequisite, mask interpretation.

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

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

Given the tool's complexity (9 params, output schema present) and annotations, the description provides the essential operational context: the upload prerequisite and mask meaning. The wait behavior and model selection are covered by the schema. This is adequate for a well-documented tool, though a note about asynchronous default could further 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?

Input schema has 100% description coverage across all 9 parameters. The tool description mostly reiterates mask semantics ('White regions in the mask indicate areas to regenerate') that are already in the schema. Since the schema fully documents each parameter, the description adds minimal extra parameter-level 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 begins with a specific verb+resource: 'Inpaint regions of an image using a mask and text prompt.' This clearly defines the tool's purpose and distinguishes it from sibling image tools like comfyui_generate_image or comfyui_upscale_image by emphasizing mask-based inpainting.

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 clear prerequisite: both image and mask must already be uploaded via comfyui_upload_image/comfyui_upload_mask. This tells the agent the necessary setup step, though it does not explicitly mention when not to use this tool or when an alternative like comfyui_transform_image would be preferred.

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

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

The description details key behaviors beyond annotations: the restart option triggers a security audit, and if False a manual restart is needed. It also explains the return value includes audit results when restart=True. This significantly increases transparency for a mutation 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 well-structured with purpose, Args, and Returns sections. Every line provides meaningful guidance, and the format is easy to parse. No unnecessary repetition.

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

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

For a tool with 3 parameters, an output schema, and annotations, the description is complete. It covers the action, parameters, behavioral differences, and return format, leaving no critical gaps for an agent to select and invoke it correctly.

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

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

Schema coverage is 100%, so parameters are well-documented already. The description adds extra value by pointing to search_custom_nodes for node_id discovery and clarifying the consequence of restart=False, going beyond the schema's 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 tool installs a custom node pack from the ComfyUI Manager registry, using a specific verb and resource. It distinguishes from siblings like uninstall/update by naming the 'install' action and registry source.

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

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

The description provides clear context for when to use the tool (installing from registry) and even references 'use search_custom_nodes to find IDs' as a prerequisite. However, it doesn't explicitly mention alternatives or when-not conditions, though the purpose statement is sufficient for basic 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?

Beyond the annotations (destructive, idempotent), the description discloses specific behavioral traits: the global vs. targeted interruption scope and the silent no-op for queued-but-not-running prompts. This is exactly the kind of context that helps an agent predict side effects. No contradiction with annotations.

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

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

The description is compact and well-structured with clear bullet-like lines distinguishing the two modes. Every sentence contributes essential information with no fluff or repetition.

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

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

The description is fully self-contained for a tool with one optional parameter and an output schema. It covers the main behavior, both modes, and the edge case of queued prompts, making it complete for effective 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?

With 0% schema coverage, the description fully compensates by explaining the meaning and effect of prompt_id: absence triggers global interrupt, presence triggers targeted interrupt, and the queued-but-not-running case. This adds significant value beyond the bare schema field.

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 function: 'Interrupt the currently executing workflow.' It specifies two modes (global and targeted) which distinguishes it from sibling tools like cancel_job or clear_queue. The verb+resource structure is unambiguous.

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

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

The description provides explicit guidance on when to use each mode ('Without prompt_id: global interrupt', 'With prompt_id: targeted'), including an important caveat about queued prompts silently no-opping. It does not explicitly mention alternative tools, but it offers clear usage context within the tool itself.

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

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

Annotations already cover read-only/idempotent safety. Description adds the paginated envelope structure and item type, providing useful behavioral context beyond what annotations declare.

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, front-loaded with purpose and return format. 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 low-complexity list tool with rich annotations and output schema, the description is complete: it states what is listed, the return envelope fields, and the item type. No major 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 covers both limit and offset with descriptions, and the description mentions pagination envelope. No additional parameter semantics beyond schema, so baseline 3.

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

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

Clearly states 'List installed ComfyUI extensions' with a specific resource and scope. Differentiates from sibling list tools by specifying 'front-end / back-end JavaScript modules registered with the ComfyUI server.'

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 alternatives or when-not-to-use guidance, but the description implies usage for querying installed extensions. Lacks exclusions compared to high-calibration example.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds valuable behavioral context by documenting the return structure, job fields (prompt_id, status, timing, outputs), and pagination response, which go beyond what annotations provide.

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

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

The description is three sentences, immediately states the core function, and adds return format details without any redundant text. Every sentence earns its place, making it both 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?

For a read-only listing tool, the description covers the core behavior, return format, job fields, and pagination. It does not mention potential edge cases like empty results or large datasets, but the output schema and high schema coverage reduce the burden on the description. Overall, it is sufficiently complete 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?

All 6 parameters have descriptions in the schema (100% coverage), so the schema already documents each parameter thoroughly. The description only provides a high-level summary of filtering, sorting, and pagination without adding new meaning beyond the parameter descriptions, so the baseline 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 uses the specific verb 'List' with resource 'jobs' and explicitly scopes 'across queue and history' with filtering, sorting, and pagination. This clearly distinguishes it from sibling tools like comfyui_get_queue (queue only) and comfyui_get_history (history only).

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

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

The description clearly states the tool lists jobs across both queue and history, providing clear context for when to use it. However, it does not explicitly name alternatives or state when not to use it, though the scope language makes the differentiation from similar tools implicit.

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

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

Annotations already establish read-only, non-destructive, idempotent behavior. The description adds useful behavioral context by disclosing the paginated envelope format and the tool's role as a precursor to other operations. There is no contradiction with annotations.

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

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

Two concise sentences deliver the tool's purpose, chaining guidance, and return shape with zero redundancy. The description is front-loaded and every sentence earns its place.

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

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

For a simple list operation, the description combined with the annotations and output schema gives complete context: what it returns, how to paginate, and how to integrate with related tools. No important gaps remain.

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

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

Input schema coverage is 100%, with both `limit` and `offset` fully described in the schema. The description does not add extra parameter semantics, but none are necessary given the complete schema.

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

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

The description opens with a specific verb and resource: 'List the model-folder types ComfyUI recognizes', and gives concrete examples (checkpoints, loras, vae, controlnet). It clearly differentiates from sibling tools by focusing on folder types rather than models, and even names the downstream tools that consume its output.

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

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

It explicitly explains how to use the output: pass any returned name as the `folder` argument to `comfyui_list_models` or `comfyui_get_model_metadata`. This provides clear context for when to use this tool, though it does not discuss exclusions 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds pagination details and folder scoping, but these are already present in the schema. No additional behavioral traits (e.g., sorting, response format) are disclosed beyond structured fields.

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

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

The description has a concise one-sentence summary followed by a structured Args block. It is appropriately sized, though the Args section repeats default values already present in the schema. Overall 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 read-only listing tool with an output schema, the description covers purpose and parameters sufficiently. It could mention that valid folder types can be obtained from comfyui_list_model_folders, but this is not essential for correct invocation.

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

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

The description explicitly explains the 'folder' parameter with examples, which is missing from the input schema. It also restates limit and offset details, slightly duplicating the schema, but the added folder semantics compensate for the schema's 67% coverage gap.

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

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

The description starts with a clear verb-resource pair: 'List available models in a folder' with examples of folder types (checkpoints, loras, vae). This clearly distinguishes it from sibling tool comfyui_list_model_folders, which lists folder names rather than 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 through the 'folder' parameter but does not explicitly state when to use this tool versus alternatives like comfyui_search_models or comfyui_list_model_folders. No exclusions 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds no additional behavioral context beyond 'all available' and pagination, which is already implied by the schema. It does not contradict annotations.

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

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

The description is concise, front-loaded with the core purpose, and includes a clearly formatted Args block. Every sentence serves a purpose, and the redundancy with schema is minimal and harmless.

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

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

This is a simple read-only listing tool with complete schema coverage, rich annotations, and an output schema. The description sufficiently covers the tool's behavior and parameters; no additional information is needed.

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

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

The input schema provides 100% coverage with detailed descriptions for limit and offset, including defaults and bounds. The description repeats these details without adding deeper semantic meaning, so it meets the baseline but does not exceed it.

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

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

The description clearly states 'List all available ComfyUI node types' with a specific verb ('list') and resource ('node types'). This distinguishes it from sibling listing tools like comfyui_list_models and comfyui_list_workflows.

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 context is clear: use this tool to list node types, with pagination parameters. However, it does not explicitly mention alternatives or when not to use it (e.g., for detailed node info, use comfyui_get_node_info). The lack of exclusions is the only gap from a 5.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context: pagination via limit/offset, the JSON envelope with filename/subfolder keys, and the relationship to comfyui_get_image. It doesn't cover edge cases or error behavior, but it goes beyond what annotations provide.

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

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

The description is well-structured with a clear first sentence followed by Args and Returns sections. It is scannable and not overly verbose, though the Args section repeats information already present in the schema. Overall it earns its place.

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

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

For a simple paginated listing tool, the description is complete: it covers purpose, pagination parameters, return envelope structure, and the next step to retrieve files. The presence of an output schema and strong annotations reduces the burden on the description. Minor gaps like clarifying what counts as an 'output' or how history is scoped are not critical.

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

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

Schema description coverage is 100% and both limit and offset are fully described in the schema. The description repeats the default values and semantics but adds no additional parameter-level meaning. Baseline 3 is appropriate since the schema carries the descriptive burden.

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

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

The description clearly states a specific verb and resource: 'List output files from ComfyUI's execution history.' It differentiates from siblings like comfyui_get_image by noting it returns metadata (filename/subfolder) rather than the files themselves, and from list_models/list_workflows by focusing on execution history outputs.

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

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

It provides clear context for when to use the tool (listing output files from execution history) and explicitly directs the caller to use comfyui_get_image with the returned keys to retrieve actual files. However, it doesn't explicitly state alternatives or when not to use the tool, such as when history details are needed from comfyui_get_history.

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

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

Annotations already convey read-only and safe behavior, and the description adds valuable context: the exact endpoint, the paginated response envelope, and the per-item structure. This goes beyond the schema and annotations to set accurate expectations about the return payload.

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

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

The description is well-organized into four concise sentences, each serving a purpose: listing the core action, giving endpoint context, distinguishing from a sibling, and describing the response. No filler or redundancy 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 tool's simplicity, strong annotations, complete parameter schema, and presence of an output schema, the description fully covers what an agent needs to select and invoke it correctly. It explains the source, the distinction from related functionality, and the return shape.

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% for limit and offset, so the baseline applies. The description mentions pagination and the response envelope, which indirectly relates to these parameters, but it does not add detail beyond what the schema already provides. It is adequate but not additive.

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

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

The description states a specific verb and resource: 'List workflow templates registered on the ComfyUI server.' It also distinguishes this from comfyui_create_workflow's hard-coded template names, which prevents confusion with a sibling tool. The intent is unmistakable.

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

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

It explicitly calls out the difference from comfyui_create_workflow's built-in templates, giving the agent a clear rule for when to use this tool instead. The endpoint context ('/workflow_templates', populated by installed packages) also clarifies the tool's scope.

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?

Beyond the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false), the description discloses key behaviors: operations execute sequentially, any failure raises ValueError, the input workflow is left unmodified because operations are applied to a deep copy (atomic). This significantly adds context and aligns with the annotations without contradiction.

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

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

The description is well-organized with a summary, behavior notes, parameter definitions, an operation reference, and an example. Every section earns its place; it is long but appropriately detailed for the complexity, and the main purpose is front-loaded.

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

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

The tool is complex due to the operation format, but the description covers all operations, error handling, atomicity, and includes a concrete example. An output schema exists, so return semantics need not be explained. The description is fully self-contained for correct invocation.

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

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

Schema coverage is 0%, so the description fully compensates by explaining both parameters: workflow is a JSON string and operations is a JSON string of an array of operation objects. It also details each operation type with fields and provides an example, making the parameter semantics exceptionally clear.

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 'Apply batch operations to a ComfyUI workflow', specifying the action (apply), the resource (workflow), and the scope (batch operations). It also distinguishes this tool from siblings like comfyui_create_workflow, comfyui_run_workflow, and comfyui_validate_workflow by focusing on modification.

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

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

The description provides clear context for when to use the tool (modifying workflows via batch operations) and detailed operational guidance, but it does not explicitly mention when not to use it or name alternative tools. The sequential/atomic behavior informs how operations are applied, but no exclusions or alternatives are stated.

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

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

The description discloses important behavioral details beyond annotations: the tool can block until completion (wait=True) and return structured results with status, outputs, and elapsed time, or return immediately with only a prompt_id (wait=False). It does not contradict any annotations and adds useful context about execution 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 tightly written: a one-sentence purpose, a single 'See also' note, and a structured Args section. Every sentence adds value with no repetition of schema details or unnecessary filler.

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

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

The tool is moderately complex (executing arbitrary workflows) and the description covers parameters, wait behavior, and return variants. The presence of an output schema lightens the need to explain return values. Missing some edge-case context like error handling or side effects, but it is reasonably complete for an execution 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?

With schema description coverage at 0%, the description fully compensates. It explains the workflow parameter's structure ('JSON string of a ComfyUI workflow (API format). Each key is a node ID, each value has class_type and inputs') and describes the wait parameter's effect and default value.

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

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

The description begins with a specific verb and resource: 'Submit an arbitrary ComfyUI workflow for execution.' This clearly states the tool's function and distinguishes it from the streaming variant by naming 'comfyui_run_workflow_stream' as a variant that emits per-node progress events.

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 provides an alternative: 'See also: comfyui_run_workflow_stream for a streaming variant...' This tells the agent when to consider the sibling tool instead. It also explains the wait parameter's behavior, giving clear context for choosing synchronous vs. asynchronous execution.

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

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

Annotations (readOnlyHint=false, idempotentHint=false) already signal that this is a mutating, non-idempotent operation. The description adds behavioral context not present in annotations: it uses a WebSocket stream endpoint, captures per-event updates like 'progress', 'executing', and 'executed', and filters events by 'prompt_id'. It also notes the return type (stream events plus final status). This is valuable, though it does not explain error handling, timeouts, or cancellation, so a 4 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 well-organized: a one-sentence summary, followed by technical behavior, usage guidance, and a parameter description. Each sentence serves a distinct purpose, and there is no filler or repetition. Despite being longer than two sentences, every part adds value, making it appropriately concise for the tool's complexity.

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

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

Given the tool's streaming complexity and the existence of an output schema, the description covers the main aspects: what the tool does, how it works internally (WebSocket), what events are captured, and when to use it. It does not mention potential error conditions, long-running behavior, or how to cancel, but the output schema likely handles return-value details. Overall, it is complete for selecting and invoking the tool correctly, with only minor gaps.

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

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

The schema has 0% description coverage for the only parameter, `workflow`. The description compensates by specifying 'workflow: JSON string of a ComfyUI workflow (API format).' This adds key meaning beyond the schema by clarifying the required format (JSON string) and the format variant (API format), which is essential for correct use. A higher score would require more detail like examples or constraints, but for a single param this is solid.

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

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

The description opens with a clear statement: 'Submit a ComfyUI workflow and return websocket stream events plus final status.' This specifies the verb (submit), resource (ComfyUI workflow), and output (stream events + final status), and it distinguishes the tool from its sibling comfyui_run_workflow by explicitly mentioning the streaming nature.

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

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

The description provides explicit guidance on when to use this tool versus the alternative: 'Use this streaming version when you need real-time per-node progress events... use the non-streaming variant for fire-and-forget submission or when you only need the final result.' This names the alternative and clarifies the intended use cases, fully satisfying the dimension.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description adds context about the return format (name, description, author, install status, version, ID) and search scope. This goes beyond annotations without contradicting them.

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

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

The description is well-structured with a clear one-line purpose followed by Args and Returns sections. It is not overly verbose, though the Args section repeats schema details. The main sentence is front-loaded and every section serves a 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 search tool with pagination and filters, the description explains the return format and search scope. It covers the essential behavior adequately. Combined with rich annotations and full schema coverage, it is nearly complete, though it could mention what 'install status' entails or pagination limits explicitly.

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

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

The input schema provides 100% coverage of all three parameters with descriptions and constraints. The description's Args section mostly duplicates this information, adding no new meaning beyond the schema. Baseline of 3 is appropriate since the schema carries the full burden.

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 searches installed custom node packs by name, description, or author, which is a specific verb+resource+scope. It distinguishes itself from sibling tools like list_extensions or get_custom_node_status by focusing on search 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?

The description implies usage for finding installed packages matching a query, but does not explicitly mention when to use this versus alternatives like listing all extensions or checking status. There are no exclusion criteria or alternative tool references, so it is adequate but lacks explicit guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds meaningful contextual detail beyond annotations: it specifies the external sources (HuggingFace/CivitAI), the return format (JSON with name, URL, size, stats), and the recommended follow-up (download_model). This gives the agent a clear behavioral model, though it does not mention rate limits, authentication, or the fact that only one source is searched at a time (as implied by the 'source' parameter).

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 three sentences: a clear purpose statement, a return-value description, and a usage link to the download tool. It is front-loaded with the primary action and has no redundant filler. 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 search tool with 5 parameters, good annotations, and an output schema, the description is sufficiently complete. It explains what the tool does, what it returns, and how to use the results (with comfyui_download_model). It does not explain default source behavior or pagination nuances, but those are covered by the schema and annotations. Minor gaps exist, but the overall context is 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?

Schema description coverage is 100%, and the parameter descriptions in the schema are clear (query, source, limit, offset, model_type). The tool description does not add much beyond what the schema already provides, except for the mention of 'HuggingFace or CivitAI' which maps to the source enum. Since the schema does the heavy lifting, 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 searches for models on HuggingFace or CivitAI, with a specific verb ('Search') and resource ('models') plus the external platforms. It distinguishes itself from sibling tools like comfyui_list_models (which lists local models) and explicitly states the return output ('JSON with search results including name, download URL, size, and stats'). This is a specific, unambiguous purpose.

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

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

The description provides a clear follow-up action ('Use comfyui_download_model with the URL to install a model'), indicating when this tool is useful in a workflow. However, it does not explicitly state when not to use it or contrast with comfyui_list_models or comfyui_get_model_metadata. The guidance is helpful but lacks explicit exclusions or alternative tool comparisons.

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

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

Annotations already mark this as read-only and idempotent. The description adds useful behavioral detail by noting that it enriches the summary with display names from the ComfyUI server 'when available', implying a conditional server call and fallback. No contradictions with annotations.

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

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

The description is compact but has some redundancy—'key parameters' in the first sentence is echoed by 'extracts models, parameters' in the second. It is structured with a clear lead sentence and supporting bullets, though it could be slightly tightened without losing meaning.

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

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

Given the simple 2-parameter schema, presence of an output schema, and safety annotations, the description adequately covers the tool's purpose and enrichment behavior. It doesn't need to explain return values because the output schema exists, so it is sufficiently complete for an agent to use correctly.

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

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

Both parameters are fully documented in the schema with descriptions (100% coverage), so the schema carries the parameter semantics. The tool description does not add parameter-specific details beyond restating 'workflow', so the 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 opens with 'Summarize a ComfyUI workflow's structure, data flow, and key parameters', which is a clear verb+resource statement. It doesn't explicitly differentiate from sibling tools like comfyui_analyze_workflow or comfyui_validate_workflow, but the summarize verb makes the intended action obvious.

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

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

No explicit guidance is provided on when to use this tool versus alternatives. The description implies it should be used for obtaining a workflow overview, but it doesn't mention exclusions or alternative tools, so usage context is only implicit.

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