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

With no annotations, the description carries the full burden. It helpfully discloses node-type behavior, especially image_input, output, and rerolls_each_run seed behavior, but it does not state whether the operation is read-only, what happens if the workflow name is invalid, or any permission/error characteristics.

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-loads the main return content before explaining special node behaviors. The first sentence is somewhat fragment-like, but each sentence provides useful information and there is little wasted text.

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

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

An output schema exists, so the description is not required to fully explain return values. It adds useful node semantics, but it remains incomplete for an agent that needs to know when to use this tool and what the required 'name' parameter represents.

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 for the single 'name' parameter. It does not explain whether 'name' means workflow name, display name, ID, or where the caller should obtain it, leaving a meaningful gap despite the small parameter set.

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 that the tool exposes a saved workflow's nodes and editable values, including per-node id, title, class, and widget inputs. It does not name a sibling tool or explicitly contrast itself with list_workflows or run_workflow, so it stops short of full 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?

There is no explicit guidance on when to call this tool versus alternatives such as list_workflows or run_workflow. The mention of run_workflow images is a cross-reference for node semantics, not usage guidance for this tool.

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

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

With no annotations, the description carries the full burden and does well: it discloses that completed runs trigger file downloads to disk, that 'saved_to' holds the local path and 'url' the public one in HTTP mode, that image results return as previews, and that wait_seconds is capped by COMFY_MAX_WAIT. It doesn't state error/retry behavior or whether repeated calls re-download, which keeps it shy of 5.

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

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

The status states are front-loaded and the remaining sentences each add distinct behavior (downloads, URL modes, previews, wait cap). Slightly dense prose but no filler sentences.

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

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

With no output schema and no annotations, the description covers return values well (saved_to, url, preview images) and the blocking semantics. The only gap is download_dir's purpose and default, which prevents a 5.

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 wait_seconds (blocking up to a cap, bounded by COMFY_MAX_WAIT) and implicitly ties downloads to download_dir, but prompt_id is never described and download_dir's null-default behavior is left to inference. Partial compensation for a 3-param tool.

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 sentence names the specific resource (a run/job) and its operation (reporting status), and enumerates the status states (queued | running | done | error), so the agent knows exactly what it gets back. It doesn't explicitly contrast with siblings like get_judged or run_workflow, keeping it at 4 rather than 5.

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

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

Usage is implied: this is the polling/status-check tool you call after run_workflow, and wait_seconds suggests a blocking poll. However, there's no explicit statement of when to use this versus get_judged for judged runs, nor any prerequisite or exclusion guidance.

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

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

With no annotations, the description carries the burden and does disclose the key behavioral trait: the response shape is state-dependent, returning an attempt log while running and adding the best image, pass/fail verdict, and per-attempt scores/problems when done. It omits polling semantics (blocking vs. point-in-time) and any rate-limit or retention notes.

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

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

A single front-loaded sentence that enumerates states first, then payloads, with no filler. It reads as a dense run-on, but every clause carries information an agent needs.

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

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

An output schema exists, so detailed return-value documentation is not required, yet the description still sketches the payload per state. What's missing is the polling contract (blocking, cadence, terminal-state behavior), which matters for a job-status tool with no annotations.

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?

One required parameter with 0% schema description coverage, so the description must compensate. It implies job_id refers to a run_judged job but never states where that id originates (presumably the run_judged response) or what happens with an unknown/expired 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?

Names a specific verb+resource: fetching status/results of a run_judged job, and enumerates the state space (running | done | error) plus what payload accompanies each state. An agent can tell it apart from run_judged, but the description never distinguishes it from the sibling get_job, which sounds equally like a status poller.

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

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

Usage is only implied: the reference to a 'run_judged job' suggests polling after invoking run_judged. There is no explicit 'use this instead of get_job' routing, no statement of when to poll versus when the job is finished, and no guidance on what to do on 'error'.

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 usefully states the return shape and the JUDGE_URL/JUDGE_MODEL prerequisites, but it does not clarify side effects, failure behavior, or permission requirements. This is partial but meaningful context beyond the schema.

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

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

The description is compact and front-loaded: it states the action, then the return values, then the environment prerequisites. Every sentence adds useful information and there is no wasted prose.

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

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

An output schema exists, so the description need not fully explain return values, though it does summarize them. However, with no annotations and 0% schema description coverage, the description leaves gaps around the path parameter and does not explain how this differs from sibling judging tools such as run_judged.

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 explains the rubric parameter as either a path to a rubric JSON file or the JSON itself, and clarifies the description parameter as what the image must show. However, the path parameter is only implicitly described as the image path, and no format or constraints are given.

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

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

The description uses a specific verb and resource: 'Judge one image with a rubric ... against a description of what it must show.' That is clear enough for an agent to understand the core operation, but it does not distinguish this tool from siblings such as run_judged or get_judged.

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

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

The description states what the tool does and mentions required environment variables, but it gives no guidance on when to use this tool instead of alternatives like run_judged. There are no explicit when-to-use or when-not-to-use conditions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not state that the operation is read-only, whether it is paginated, what happens on invalid folders, or what permissions are required. For a listing tool the risk is low, but the description still omits meaningful behavioral context beyond the basic resource description.

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 efficient sentence with no wasted text. The core distinction between listing folders and listing files in a folder is front-loaded, though the telegraphic noun-phrase style slightly limits clarity.

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

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

The tool is simple with one optional parameter, and an output schema exists so return values need not be explained. The description covers the essential resource distinction and gives folder examples, but it lacks usage guidance and explicit default behavior. It is minimally adequate for this complexity level.

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 single folder parameter. It does provide useful semantics by explaining that the folder selects files within one folder and gives concrete examples like 'checkpoints', 'loras', and 'diffusion_models'. It does not explicitly state the null/default behavior or path rules, so it only partially compensates.

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 identifies the resource clearly: model folders and files within a folder. However, it is a noun phrase without an explicit verb such as 'list', and it does not differentiate this tool from sibling listing tools like list_workflows or server_status. The purpose is inferable but not stated with verb+resource precision.

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

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

There is no explicit guidance on when to use this tool versus alternatives. It implies that omitting the folder argument lists folders and providing one lists files, but this is left to inference rather than stated as usage guidance. No exclusions or prerequisites 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only listing by saying 'Names of the workflows,' but does not explicitly state that it performs no mutation, requires no special permissions, or has any 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 very short with no wasted words, but it is an incomplete sentence fragment rather than a front-loaded, well-structured statement. It under-specifies rather than being overly verbose.

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 zero-parameter schema and the presence of an output schema, the description covers the essential resource and scope. However, it omits when to prefer this tool over siblings like describe_workflow, leaving a meaningful contextual gap for an agent choosing among tools.

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

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

The tool has zero parameters, so there are no parameter semantics to explain. The baseline score of 4 applies because the description need not compensate for undocumented 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 identifies the resource (workflows) and scope (saved in the ComfyUI editor's Workflows panel), but it is a noun phrase rather than an explicit verb such as 'List'. It does not distinguish the tool from siblings like describe_workflow or run_workflow, leaving the exact action somewhat implied.

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

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

There is no guidance on when to use this tool versus alternatives such as describe_workflow or run_workflow. The description only states what it returns, not the context or conditions that warrant calling it.

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

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

With no annotations, the description carries the burden and discloses real behavior: it runs in the background and returns a job id immediately, it requires the JUDGE_URL and JUDGE_MODEL environment variables, it retains the best result across iterations, and on a retry the judge's problems are appended to prompt_field. It still does not say what happens on failure, how many iterations, or whether the saved workflow definition is modified.

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

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

Front-loaded with the core behavior in the first sentence, then parameter notes, with no filler. The dense semicolon-chained param notes read a bit like shorthand, but every clause conveys something actionable.

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

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

Covers the async contract, the env prerequisites and the retry behavior, and an output schema exists so return values need no explanation. However, for an 8-parameter tool with 5 required params and zero schema coverage, a required parameter ('name') and the set/images/download_dir inputs are never explained, which is a real gap for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry all parameter meaning. It explains prompt_field (with a concrete format example like "Positive.text"), description, rubric (file path or inline JSON), and implies prompt, but leaves the required 'name' plus 'set', 'images' and 'download_dir' entirely undocumented.

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

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

States a specific verb and resource ('Run a saved workflow under the harness') and spells out the actual loop (generate -> judge -> fix -> judge, keeping the best result), which is what separates it from run_workflow and judge_image. It also names the polling sibling get_judged, so the agent can place the tool in the flow without opening any schema.

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

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

Gives clear operational guidance: the call is asynchronous, returns a job id immediately, and must be followed by polling get_judged(job_id). It does not state when to prefer this over run_workflow (plain run) or judge_image (single judgement), so selection between siblings is left partly 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?

With no annotations, the description carries the full behavioral burden. It usefully explains image upload behavior, waiting/downloading, the COMFY_MAX_WAIT cap, and fallback polling via get_job, but it omits side effects, permissions, and what run_workflow returns when it does not wait.

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 then uses compact parameter-specific lines. Examples are purposeful and there is no redundant prose.

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 complex seven-parameter execution tool with no annotations and no output schema, so the description needs to do more. It covers most important inputs and polling behavior, but omits download_dir semantics and does not clarify the return/job model when wait_seconds is zero.

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

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

Schema description coverage is 0%, so the description must compensate. It does so well for set, images, enable, bypass, and wait_seconds with concrete examples, though it leaves download_dir and the obvious name parameter unexplained.

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

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

The description opens with a specific verb and resource: 'Run a saved workflow with your inputs.' That is clear enough to distinguish it from list/describe workflow tools, but it does not explicitly differentiate it from the similar-sounding run_judged sibling.

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

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

Usage is implied by requiring a saved workflow name and by the wait_seconds note, which says to poll get_job instead of waiting. However, it does not state when to choose run_workflow versus run_judged or other execution siblings.

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

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

No annotations are supplied, so the description carries the behavioral burden; it does communicate that this is a non-mutating status read and names the returned data groups. It says nothing about failure behavior (e.g. when the server is unreachable) or cost/latency, which are the traits an agent would most want for a health probe.

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

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

A single compact clause, front-loaded with the resource and then the returned fields; no filler. The fragmentary 'which server' phrasing is slightly telegraphic but does not cost meaning.

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

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

With an output schema present, the description needn't spell out return shapes, and with no inputs there is no parameter burden. The only gap is behavioral edge cases (unreachable server, authentication), which a status tool would ideally mention.

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 declares zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter semantics are missing.

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 the resource (ComfyUI server) and enumerates exactly what the tool surfaces: which server, version, GPU/free VRAM, and queue length. That enumeration makes it clearly distinct from the workflow/model/job siblings, though the verb ('get'/'report') is left 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?

Usage is inferable but never stated: an agent can guess this is the diagnostic/health-check call before or during workflow runs, but there is no explicit 'use when' phrasing or mention of any alternative tool. For a zero-parameter status endpoint that is likely acceptable, hence the implied-usage 3 rather than lower.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the write destination and the key return value, but it omits important mutation details such as overwrite behavior, supported formats, size limits, and permission or authentication requirements.

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

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

The description is a single front-loaded sentence with the action, destination, and return value stated efficiently. There is 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?

Given that an output schema exists, return-value details are mostly covered elsewhere, and the description adequately explains the basic call flow. However, with no annotations and 0% schema description coverage, the missing explanation of the optional `name` parameter and upload constraints leaves meaningful gaps.

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

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

Schema description coverage is 0%, so the description must explain both parameters. It implies that `path` refers to a local image, but it does not clarify path format or location, and it does not explain the optional `name` parameter at all.

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 (upload a local image) and names the destination (server's input folder). It also connects the output directly to the sibling tool run_workflow, so the agent can distinguish this preparatory upload step from workflow execution.

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

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

It gives clear context for when to use the tool: before run_workflow when an image must be uploaded and its returned name supplied. It does not explicitly cover exclusions or alternatives, such as remote URLs or directly passing existing server-side images.

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