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

The description goes beyond the destructiveHint annotation by specifying exactly what happens in each state: pending jobs are removed from the queue, running jobs are interrupted, and omitting prompt_id affects the currently running job. This is valuable behavioral context and does not contradict the annotation.

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

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

Two concise sentences cover the action, the conditional behavior, and the default behavior without any wasted words. The most important information 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?

Given a single optional parameter, a destructiveHint annotation, and an output schema, the description provides all necessary operational details: what the tool does, how it behaves for pending versus running jobs, and how prompt_id affects targeting. Nothing essential 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?

With 0% schema description coverage, the description compensates by explaining the meaning of omitting prompt_id and implying that prompt_id identifies the specific job to cancel. It could more explicitly state where to obtain prompt_id, but the core semantic is 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 uses a specific verb ('Cancel') and resource ('a job'), and clearly distinguishes the two behaviors: removing a pending job from the queue or interrupting a running job. It is unambiguous and distinct from sibling tools, none of which are cancellation tools.

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

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

The description provides clear context for when to use the tool and how to target a specific job versus the currently running one. It does not explicitly mention alternatives, but no alternative cancellation tool exists among the siblings, so the omission is acceptable.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool resolves Set/Get nodes, reroutes, and bypassed nodes, and notes the subgraph limitation. It also explains the include_bypassed parameter's effect. However, it does not mention the behavior of the overwrite parameter or error conditions, but the core behavioral details are adequately covered.

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 the primary purpose, adds a limitation sentence, and then includes an Args section for parameter clarification. Every sentence contributes value without unnecessary fluff, making it easy for an agent to quickly understand the tool's function and usage.

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 largely complete for a conversion tool: it states the output location, resolves node types, and explains a parameter. However, it omits any explanation of the overwrite parameter's behavior, which is essential for understanding how the tool handles existing files. Given the output schema exists, return value details are not needed, but the missing parameter semantics reduce 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?

The schema description coverage is 0%, so the description must compensate. It provides context for workflow and name through the main sentence, and explicitly explains include_bypassed in the Args section. However, the overwrite parameter is completely unexplained, and the description does not fully cover all parameters, leaving a gap for a required boolean parameter.

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

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

The description clearly states the tool's purpose with a specific verb (convert), resource (UI-format workflow), and output (API format saved to workflows/api/<name>.json). It distinguishes itself from siblings by focusing on conversion rather than running, saving, or managing workflows, and includes specific details like resolving Set/Get nodes and the subgraph limitation.

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 by noting the tool works 'without having to run it first' and explicitly excludes workflows with subgraphs. While it does not name alternative tools directly, the context implies when to use this versus running or saving workflows. It gives a practical usage scenario and a clear exclusion, but lacks explicit contrast with sibling tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core action (unloading models, freeing cached memory) but omits consequences such as slower subsequent model reloading or whether running workflows are interrupted. Since there is no annotation contradiction, and the primary behavior is disclosed but side effects are not, a middle score is appropriate.

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

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

The description is a single sentence front-loaded with the key action and resource, containing no filler or redundant phrasing. It is efficient, though it is arguably too thin to carry the necessary usage and behavioral context on its own.

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 boolean parameter and an existing output schema, the core action is conveyed adequately. However, missing usage context and behavioral side effects (impact on active jobs, reload latency) leave the description only minimally sufficient. It covers the 'what' but not the 'when' or 'what happens next'.

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

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

Schema description coverage is 0%, so the description must compensate for the lone 'unload_models' boolean parameter. It partially does by mentioning model unloading, but it does not clarify behavior when the parameter is false (it defaults to true) or whether cached memory is freed independently of model unloading. The description adds some meaning but leaves the false-case semantics ambiguous.

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 ('unload models and free cached VRAM/RAM') against a clear resource. This is implicitly distinct from operational siblings like comfyui_cancel, comfyui_queue, and comfyui_status, which address different concerns. No sibling is explicitly named, but the memory-freeing purpose is unambiguous, so the differentiation is clear even if implicit.

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

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

There is no guidance on when to use this tool versus alternatives. A memory-freeing tool would benefit from context such as 'use when running out of VRAM before a heavy workflow' or warnings about whether it affects active jobs. No exclusions or alternative routes are mentioned, so the agent must infer appropriate invocation from the name alone.

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

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

With no annotations, the description carries the full burden, and it delivers: it discloses size rounding to multiples of 16, default sizing from the first image, transparent inputs being flattened onto white, trim defaulting to on, upscale toggling extra output, output labels, and checkerboard previews. This is far more behavioral transparency than annotations alone would 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 dense but every sentence earns its place, and the core purpose is front-loaded. The level of detail is justified by 13 parameters and zero schema descriptions, with no filler 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?

For a 13-parameter tool with no output schema and no annotations, the description is unusually complete: it explains the workflow, image-reference syntax, resize behavior, output labels, and extra overrides. It falls just short of full completeness because wait/timeout/seed semantics and the return structure are left implicit.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for prompt, images, width, height, transparent, upscale, trim, extra, and workflow. However, seed, wait, preview, and timeout receive little or no explicit explanation, leaving minor 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 sentence names a specific verb ('generate or edit'), a specific resource type ('single asset': object, sprite, icon, character cut-out), and the exact output ('PNG with transparent background'). This strongly differentiates it from the sibling generate_image/generate_video/generate_audio tools even though no sibling is named.

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 clearly states when to use the tool: for generating or editing an asset with transparency via the default 'asset' workflow. It gives clear context (single asset, subject-only prompts, image references) but does not explicitly mention when to choose e.g. comfyui_generate_image or comfyui_upscale instead.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It adds useful behavior ('Empty arguments keep the workflow's own values', `extra` overrides, `workflow` swaps presets), but does not disclose async behavior, the meaning of `wait`/`timeout`, or what the call returns, which are significant for a generation tool.

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

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

The description is compact, front-loaded with the primary purpose, and every sentence provides actionable information. It avoids redundancy and presents the most important usage semantics in a scannable format.

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 10 parameters, no annotations, and no output schema, the description covers the core generation workflow but leaves important operational details unstated, such as how results are returned, how `wait`/`timeout` behave, and what `negative_prompt` does. It is adequate for basic use but has clear gaps for reliable 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?

Schema description coverage is 0%, so the description must compensate. It explains five parameters (`prompt`, `lyrics`, `duration`, `extra`, `workflow`) clearly, but omits `seed`, `steps`, `negative_prompt`, `wait`, and `timeout`, leaving half the parameters semantically unclear despite the 'empty arguments' hint.

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 action ('Generate audio/music') and the resource ('default audio workflow'), which distinguishes it from sibling image, video, and asset generation tools. Backticked parameter names reinforce the core function without ambiguity.

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 makes the intended use context clear: audio/music generation via the preset 'audio' workflow. It explains how to customize prompt, lyrics, duration, and workflow, but does not explicitly contrast with generic alternatives like comfyui_run or other generation tools, so exclusions are left to inference.

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

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

Describes workflows, size behavior (default 1024x1024, editing uses <image1> size), upscale toggle, and label outputs. But does not mention async vs blocking, return format, or error handling. Since there are no annotations, the description carries the burden; it covers major behaviors but not all.

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?

Dense but well-organized: first sentence states purpose, then size behavior, then customizations. No fluff; every sentence adds value. Slightly long but necessary for the 17-param tool.

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

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

Covers core workflows, size, and customization. However, lacks output details (image format, async behavior), error conditions, and does not mention how `preview`, `timeout`, `batch_size`, `cfg`, `seed`, `steps` interact with defaults. Some parameters have defaults but semantics are implied, not explicit.

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

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

With 0% schema description coverage, the description must explain all parameters. It explains images, prompt placeholders, size (width/height, aspect_ratio, megapixels), upscale, extra, workflow, and empty arguments meaning. Almost every parameter is explicitly defined, making up for the schema 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?

States a clear purpose: generate or edit images with the default image workflow. Disambiguates generation vs. editing based on presence of `images`. Differs from siblings like comfyui_generate_video/audio and comfyui_run by focusing on images with preset 'image'.

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

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

Explicitly explains when to use without `images` (generate) and with `images` (edit), and how to reference image placeholders. Notes that editing requires workflow support and mentions alternatives like `workflow` parameter to swap presets. But does not contrast with siblings like comfyui_run or comfyui_generate_asset.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explicitly discloses the async/slow behavior, default immediate return, the need to poll comfyui_job_status, and that empty arguments preserve workflow defaults. It does not cover failure modes or exact return payload, but the most operationally critical behaviors are transparent.

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

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

The description is front-loaded with the core action and every sentence earns its place: input formats, duration/length semantics, async behavior, defaults, extra overrides, and workflow swapping. There is no filler or repetition of schema information.

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

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

For a 16-parameter tool with no annotations and no output schema, the description covers the essential operational facts: how to provide images, how to choose duration vs length, how to override defaults, and how to handle the slow async lifecycle. It does not spell out wait/timeout behavior in detail, but the provided guidance is sufficient for correct invocation and follow-up.

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 successfully explains the ambiguous parameters: image/image2 input formats, duration vs length mapping, extra raw overrides, and workflow preset substitution. The remaining parameters (fps, seed, width, height, prompt, etc.) are reasonably self-explanatory from their titles, so the gap is mostly covered.

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

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

The description opens with a specific action and resource: 'Generate a video with the default video workflow (preset "video")'. This clearly distinguishes it from sibling generation tools like comfyui_generate_image and comfyui_generate_audio, and the workflow-swap note further clarifies its scope.

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

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

The description gives clear usage context: use it to generate video, and it instructs the agent to poll comfyui_job_status because the video is slow and returns immediately by default. It does not explicitly list when-not-to-use or name alternatives, but the video-generation scope is unambiguous enough for 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?

Annotations declare readOnlyHint=true, and the description adds meaningful behavioral details beyond that: files expose a streaming/seeking-capable url and, for media, a browser player page. It also discloses the include_temp behavior for temporary PreviewImage files, which is useful context not present in the annotations.

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

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

The description is compact and front-loaded: the core purpose and output characteristics appear in the first sentence, followed by a concise args block. Every sentence earns its place, with no filler or repetition of schema information.

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

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

For a simple two-parameter read-only list tool, the description covers the key context: when to call it, how to identify the job, and what the returned files look like. It could mention behavior when the job is not finished or when no outputs exist, but given the annotations and simplicity, it is largely 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%, so the description carries full responsibility for parameter meaning. It explains prompt_id as the job id returned by comfyui_run or a preset tool, and include_temp as a flag for temporary preview files, adding real semantics beyond the raw schema types and defaults.

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 files produced by a finished job," and enumerates file types (images, videos, audio). This clearly differentiates it from sibling tools like comfyui_job_status or comfyui_history by focusing on retrieving output artifacts rather than job state or workflow 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 specifies when to use the tool: after a job is finished, using a prompt_id returned by comfyui_run or a preset tool. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to know this is the retrieval step after job completion.

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 openWorldHint=false, covering the safety profile. The description adds value beyond that by disclosing ordering behavior ('newest first') and scope (it includes web-UI-run jobs, not just API runs). It does not cover secondary behaviors like whether failed jobs are included or how far back history extends, but with the annotation burden already handled, the added context is meaningful.

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

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

Two sentences, zero filler. The purpose with ordering and scope is front-loaded in the first sentence, and the second sentence earns its place by connecting the tool to a concrete downstream action (comfyui_save_workflow). Nothing extraneous.

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 low-complexity tool — one optional parameter, an output schema present (so return values need no explanation), and annotations covering read-only behavior. The description covers what is listed, the ordering, the inclusion scope, and a key downstream use. The only notable gap is ambiguity over whether 'finished' includes failed/canceled runs, but for a simple list tool this is minor.

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

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

Schema description coverage is 0% and the description makes no mention of the single `limit` parameter, so it fails to compensate for the gap the rubric requires at low coverage. The parameter is salvageable only because the name 'limit' with default 10 is self-evident and the list context makes its role apparent, but the description itself adds no semantics to 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 clear purpose: listing recent finished jobs, newest first, with an explicit scope qualifier ('including ones run from the ComfyUI web UI'). The verb is implied rather than explicit ('Recent finished jobs' instead of 'List recent finished jobs'), and while the coverage qualifier helps set it apart from API-only histories, it never explicitly names a sibling it is not — differentiation from comfyui_job_status and comfyui_status is left to inference.

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

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

The description gives clear, actionable context: this tool is the source of prompt_ids for turning past runs into workflows via comfyui_save_workflow, which tells an agent exactly when and how to chain the tool. However, it provides no exclusions or explicit comparison against sibling tools like comfyui_job_status (single-job status) or comfyui_status (server status), so it stops short of full when/when-not 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?

The readOnlyHint annotation already establishes that this is non-mutating. The description adds useful behavioral details beyond that: pending jobs include a queue_position, and finished jobs expose their output files. This clarifies response semantics without contradicting the annotations.

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

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

Two concise sentences with no filler. The status list is front-loaded, and the output-file note is a single, relevant trailing sentence.

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

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

For a single-parameter, read-only tool with an output schema, the description covers the important semantic ground: possible statuses, queue_position for pending jobs, and output files for finished jobs. It could add explicit routing guidance against siblings like comfyui_history or comfyui_get_output, but that is more of a usage-guideline gap.

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

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

There is only one required parameter, prompt_id, and its purpose as the job identifier is inferable from the parameter name and the tool's job-status scope. However, schema description coverage is 0% and the description never explicitly maps prompt_id to the job being queried, so it adds minimal 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?

States exactly what the tool reports: the status of a job, and enumerates the possible status values including the queue_position nuance for pending jobs. It is clearly a read/status tool and distinguishable by the 'job' scope from the likely server-level comfyui_status sibling, though it does not explicitly name or compare siblings.

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

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

The intended use is implied: check the status of a previously submitted job, likely after comfyui_run. No explicit when-to-use or when-not-to-use guidance is given, and no alternatives such as comfyui_history or comfyui_get_output 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 declare readOnlyHint=true, so the safety profile is established. The description adds that the operation lists installed model files and that omitting folder lists every folder, but it does not describe output shape or pagination; with the output schema present, this is acceptable but not exceptional.

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 lines plus a compact args section, with the purpose front-loaded. Every sentence adds useful information; there is no filler or repetition of the schema.

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

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

For a two-optional-parameter list operation with readOnly annotations and an output schema, the description covers what an agent needs: what is listed and how to filter. No prerequisites, side effects, or return-value caveats are necessary.

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

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

Schema description coverage is 0%, so the description carries the full burden of explaining parameters. It does so thoroughly: folder gives specific example values and a default behavior, and search specifies case-insensitive substring matching on file names.

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 installed models,' which unambiguously identifies what the tool does. This distinguishes it from sibling tools focused on workflows, jobs, images, and generation, so an agent can select it without inspecting schemas.

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

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

The description provides clear parameter-level guidance: a closed set of folder examples, 'Omit to list every folder,' and the search filter semantics. It does not explicitly name alternative tools, but no sibling offers model listing, so the context is sufficient and no exclusions are needed.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does note that clearing only affects pending jobs and that the running job is unaffected—important scoping information. However, it does not elaborate on side effects of clearing (e.g., whether pending jobs are permanently lost, any confirmation needed) or the precise nature of the 'list' output. It adds some transparency but leaves gaps.

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

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

The description is a single, well-structured sentence that delivers the core purpose and the key caveat about the running job. It is front-loaded with the primary action and uses no filler. 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?

For a tool with one optional parameter and an output schema (not shown), the description covers the main actions and their effects. It does not describe the output format, but the presence of an output schema mitigates that need. It also doesn't hint at error conditions or when the tool might be unavailable (e.g., no ComfyUI connection), but overall it is sufficiently complete for simple usage.

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

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

The description explicitly explains the action parameter's values and their effects: 'list' shows jobs, 'clear' removes pending ones. This adds meaning beyond the raw enum in the schema, which only lists possible values without descriptions. Since schema description coverage is 0%, this textual explanation is critical and well executed.

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 dual function: showing running/pending jobs and clearing pending jobs via the action parameter. It uses specific verbs ('Show' and 'clear') and identifies the resource (jobs). This distinguishes it from siblings like comfyui_status (which might show system status) and comfyui_job_status (which focuses on a single job).

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

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

The description implies usage context (view jobs or clear pending ones) but does not explicitly contrast with sibling tools. For instance, it doesn't advise when to use comfyui_queue over comfyui_status or comfyui_history for job listing. The mention of the action parameter provides some guidance, but exclusionary or alternative conditions are absent.

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

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

With no annotations, the description carries the full behavioral burden. It discloses important runtime behavior: randomize_seed prevents cached results, wait blocks until completion and returns outputs, timeout bounds the wait, and preview returns downscaled images. It does not mention side effects like queue consumption or failure modes, but the provided behavioral details are substantial.

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

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

The description is front-loaded with a one-sentence summary followed by a tight Args list. Each parameter line adds necessary detail, including examples and edge-case behavior, with no filler 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 thorough for a complex 8-parameter tool with no output schema, explaining all parameters and key behaviors. However, it does not state that at least one of workflow or workflow_json is required, nor what is returned when wait=false. These are minor but meaningful gaps for an agent invoking the tool.

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

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

Schema description coverage is 0%, yet the description documents all 8 parameters with meaningful semantics and examples. It distinguishes friendly params from raw node inputs, explains workflow_json as an alternative to workflow, and clarifies the role of randomize_seed, wait, timeout, and preview. This fully compensates for the bare schema.

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

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

The opening line 'Queue a workflow on ComfyUI' uses a specific verb and resource, making the tool's core function immediately clear. It is distinct from sibling tools like comfyui_status or comfyui_workflow_info, and the workflow-focused action differentiates it from generation helpers.

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

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

The description explains what the tool does but provides no explicit guidance on when to choose it over alternatives such as comfyui_generate_image or comfyui_workflow_info. There are no exclusion criteria or 'use this instead of X' statements, leaving the agent to infer the appropriate context.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses the write action and the file location, and mentions a prerequisite (running the job once). However, it omits details about overwrite behavior, error conditions, or side effects beyond saving. It doesn't contradict any annotations (none exist).

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

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

Two sentences with no fluff. The main action is front-loaded, and the second sentence adds context about the use case. Every word contributes 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?

Given the tool's complexity (3 params, 0% schema coverage, no annotations), the description is incomplete. It doesn't explain parameter semantics, edge cases (e.g., overwrite behavior, existence checks), or error conditions. The presence of an output schema partially helps, but the description should provide more operational detail for an agent to use it correctly.

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

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

Schema description coverage is 0%, so the description should compensate. It indirectly explains 'name' (file path) and implies 'prompt_id' (past job), but doesn't explicitly define either parameter. 'overwrite' is not addressed at all, leaving its purpose to inference from the boolean type. The description adds little beyond the schema's basic property types.

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 action (save an API-format workflow), the resource (past job's workflow), and the destination (workflows/api/<name>.json). It also explains the workflow's role in converting UI-format to runnable, which distinguishes it from related tools like comfyui_convert_workflow.

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

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

The description provides a clear usage context: run a job in the ComfyUI web UI, then save it from comfyui_history. It implies the tool is for post-run saving and references comfyui_history as the source. It doesn't explicitly list alternatives or when not to use, but the sequential hint is helpful.

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, and the description is consistent with a no-side-effect status read. It adds useful context by disclosing that the tool probes reachability and reports queue size, GPU/VRAM/RAM usage, and versions, which goes beyond the bare read-only annotation.

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

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

A single efficient sentence that front-loads the tool's purpose ('ComfyUI health') and then lists the key data points. Every word earns its place and there is 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?

For a zero-parameter read-only status tool with an output schema already present, the description is complete. It communicates what the agent can expect to learn from the tool without needing to explain return values or parameters.

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

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

The input schema has zero parameters and 100% schema description coverage, so the description carries no parameter burden. The baseline of 4 applies because there are no parameters whose meaning needs to be clarified.

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

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

The description names the resource ('ComfyUI health') and enumerates concrete contents (reachability, queue size, GPU/VRAM/RAM usage, versions), so an agent can tell it apart from sibling tools like comfyui_queue or comfyui_free_memory without opening schemas.

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

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

The description implies this is the general health/readiness check for ComfyUI, but it never states when to prefer it over comfyui_queue for queue details or comfyui_free_memory for memory relief. An agent must infer the use case from the word 'health'.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the upload destination and source formats, but omits important mutating-tool details such as whether files are overwritten, how file names are derived, size limits, auth/permission needs, or how the tool actually fetches remote URLs.

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 compact sentences with the key purpose front-loaded. The Args section adds necessary parameter detail without 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?

For a single-parameter upload tool with an output schema present, the description covers the essential invocation context: what to upload, where it goes, and why it is used. The main omitted context is behavioral rather than structural, and it is already penalized in the behavioral transparency dimension.

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%, and the description fully compensates for the only parameter by enumerating accepted forms: http(s) URL, data URI, or raw base64 content. This is essential information the schema alone does not provide.

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 states a specific verb ('Upload'), a clear resource ('ComfyUI's input folder'), and an intended downstream use ('for use in Load* nodes'). This clearly distinguishes it from siblings that generate, view, or manage 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 phrase 'for use in Load* nodes' gives some usage context, and the accepted source formats are listed. However, it never explicitly says when to choose this tool versus an alternative, nor does it mention prerequisites like 'use this before running a workflow that references the file.'

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

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

With no annotations, the description carries the behavioral burden. It usefully discloses accepted image input forms, default-preserving behavior for empty arguments, and extra/workflow overrides. However, it does not state what the tool returns, whether it blocks/wait behavior, or any side effects beyond possible file placement.

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

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

The description is compact and front-loaded with the main purpose. The image-format guidance is valuable and all sentences earn their place, though it is slightly dense with backticks and parenthetical references.

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

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

The tool has 7 parameters, no annotations, and no output schema. The description covers the main entry points but omits the return contract and the behavior of wait/preview/timeout, leaving an agent without enough context to fully interpret the result of the call.

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 adds real meaning for image, extra, and workflow, and notes that empty arguments keep the workflow's own values. It does not explain scale, wait, preview, or timeout, though these are mostly inferable from their names and defaults.

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 sentence names a specific operation and workflow preset (upscale, preset 'upscale'), making it immediately clear what the tool does and distinguishing it from siblings like comfyui_generate_* or comfyui_run.

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

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

The description gives a clear use case: upscaling an image with the default upscale workflow. It does not explicitly rule out siblings or list alternatives, but the scope is specific enough for an agent to select it over the other ComfyUI tools.

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

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

Annotations already declare readOnlyHint=true, so the description does not need to restate that. It adds valuable behavioral context: the image is downscaled to max_size px and returned inline. This goes beyond the schema and annotations by explaining the visual output and the scaling behavior, which helps the agent understand what to expect.

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

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

Two sentences with no filler. The purpose is front-loaded, the two usage modes are clearly separated, and the example is integrated without extra verbosity. Every word contributes to understanding.

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 has 6 optional parameters and no output schema, the description covers the essential information: how to specify the image and the downscaling behavior. It does not address edge cases like what happens if neither prompt_id nor filename is provided, but for a simple read-only view tool, this is adequate. The example clarifies a common use case.

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 explains the two parameter groups (prompt_id+index vs filename+subfolder/type) and mentions max_size in the context of downscaling. It also provides an example that hints at the type enum (input). This adds meaning beyond the bare schema names, though it could be more explicit about defaults and the meaning of each 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 states a specific verb and resource ('Return an image so it can be seen inline') and clearly distinguishes between two ways to specify the image (prompt_id+index or filename+subfolder/type). This differentiates it from sibling tools like comfyui_get_output or comfyui_upload_file, and includes a concrete example (uploaded input image).

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

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

The description provides clear instructions on how to choose between the two argument modes, and includes an example use case. It does not explicitly state when not to use this tool versus alternatives, but the purpose is specific enough that an agent can infer appropriate usage. The guidance is practical and actionable.

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

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

The readOnlyHint annotation already covers the safety profile, and the description adds useful behavioral detail about the output scope: friendly params and every node's literal inputs. It does not describe error behavior for invalid workflow references, but that burden is partly reduced by the output schema and read-only annotation.

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

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

One tight, front-loaded sentence states the action and resource, then adds a precise parenthetical explaining the input naming convention. There is no filler and every part of the sentence earns its place.

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

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

The tool is simple, has an output schema, and the relationship to comfyui_run is clear. However, the unspecified `workflow` parameter format leaves an invocation gap that could prevent an agent from calling the tool correctly, so the description is adequate but not 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 0% schema description coverage, the description needed to explain what the `workflow` parameter accepts, but it only reuses the word "workflow" without clarifying whether it is an ID, a file path, a workflow name, or a JSON payload. Since this is the only required parameter, the lack of semantic guidance is a significant 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 names a specific action, "Show", and a specific resource: a workflow's friendly params and every node's literal inputs. It also explicitly links the output to comfyui_run's `params`/`inputs` mechanism, which distinguishes it from the mutation/execution sibling tools.

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

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

It clearly implies when to use the tool: before running or modifying a workflow via comfyui_run, since it tells you what can be changed and how to reference inputs. It does not explicitly enumerate exclusions or name alternative tools, but the use context is unambiguous.

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

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

The readOnlyHint annotation already signals a safe read operation, and the description adds useful context: it covers local files as well as ComfyUI-saved workflows, and reveals the returned metadata (friendly params and preset category). This adds value beyond the annotation without contradicting it.

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

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

The description is a single, front-loaded sentence that states the action first and then the source scope and included metadata. It contains no filler, though 'friendly params' and 'backs' are slightly informal and could be clearer.

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 parameterless, read-only listing tool with an output schema present, the description covers what is listed, where workflows come from, and what metadata is returned. The output schema can carry the detailed return structure, so the description is sufficiently complete 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?

The tool has zero parameters, so there is no parameter burden for the description to carry. The baseline for zero-parameter tools is 4, and the description appropriately focuses on output scope rather than parameter details.

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

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

The description opens with a specific verb and resource: 'List available workflows', and clarifies that it covers both local files and workflows saved in ComfyUI, plus the friendly params and preset each workflow backs. This clearly distinguishes it from sibling tools like comfyui_workflow_info, comfyui_run, or comfyui_save_workflow.

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

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

The description implies the tool is used to enumerate available workflows before selecting one, but it does not explicitly state when to prefer it over comfyui_workflow_info or other alternatives. There are no exclusions or explicit when-to-use/when-not-to-use cues.

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