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

With no annotations provided, the description carries the full behavioral disclosure burden, and it does so thoroughly. It discloses async background execution, fast return behavior, exact pending/completed/failed response shapes, same-URL repetition while pending, one-time state clearing, automatic reaping of stuck children, never returning secrets, and ComfyCliError failure modes. This goes far beyond basic tool descriptions.

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 longer than typical, but every sentence earns its place: it front-loads the core purpose, then covers async behavior, response states, retry semantics, error handling, and fallback. The structure is logical and dense without 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?

Given there is no output schema and no annotations, the description is remarkably complete for correct invocation. It documents the full response lifecycle, the companion tool to use for confirmation, error conditions, and a fallback path. An agent has enough information to invoke the tool, interpret results, and handle failures without guessing.

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 document beyond the empty schema. The baseline of 4 applies because with no params the description cannot add parameter-level detail and does not need to; it instead focuses its space on behavior and return semantics.

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

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

The first sentence states a specific verb and resource: 'Start Comfy Cloud sign-in; returns an OAuth URL for the USER to open.' It also explicitly distinguishes this tool from auth_status by noting that auth_status is 'the authority on credentials' while this tool only reports how the login process ended, giving agents clear sibling differentiation.

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

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

The description gives explicit usage flow: give the user login_url, let them finish in their browser, then confirm with auth_status. It warns that calling again while pending returns the same URL and that only one flow runs at a time, which is a clear when-not-to-call constraint. It also names manual 'comfy cloud login' as a fallback alternative.

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

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

No annotations exist, so the description carries the full burden. It discloses that the operation is read-only, never returns secrets, and explains the exact payload structure including fields and edge cases (e.g., the blind spot with COMFY_API_KEY, and the fallback for non-dict payloads). This is exceptionally 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 structured and front-loaded: purpose first, then usage, then return details, then edge cases. The blind-spot section is clearly labeled and adds critical information without redundancy. Every sentence 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 has no parameters and no output schema, the description fully covers what an agent needs: what it does, when to use it, what it returns, and important caveats. The edge-case handling for non-dict payloads is especially thorough.

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 nothing to explain. The baseline for zero-parameter tools is 4, and the description correctly focuses on the return value rather than parameters. No additional parameter info is needed.

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

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

The description states a specific purpose: reporting Comfy Cloud credential status for partner-API nodes. It explicitly says it is read-only and never returns secrets, and it names the underlying command (`comfy cloud whoami`). This clearly distinguishes it from the sibling `auth_login`, which handles authentication rather than status.

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

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

It provides an explicit call condition: 'Call before running a workflow whose nodes hit partner APIs (Seedream / Veo / Kling / Gemini / …) to self-diagnose.' This tells the agent exactly when to use it and why. Though it doesn't list alternatives, there is no direct sibling for status checking, so the guidance is sufficient.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses the truncation hazard, exact expected payload sizes for each mode, and the historical failure where the default exceeded the cap. It also tells the agent what each variant returns, so the response shape is predictable before invocation.

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 longer than average but every sentence earns its place: purpose is front-loaded, the mode breakdown is scannable, and the measured sizes directly support the truncation warning. The historical note about the previous default is relevant because it justifies the current default behavior.

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

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

For a tool with no annotations, no output schema, and only 0% parameter schema coverage, the description is complete: it covers purpose, when to use each variant, argument semantics, output size, and a known failure mode. Nothing an agent needs to call this tool correctly is missing.

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

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

Schema description coverage is 0%, so the description must fully compensate, and it does: command is explained as 'return ONE schema body by name' and schemas_only is mapped to the CLI flag with concrete size consequences. Example calls like discover(command='run') make parameter usage unambiguous.

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 exact resource ('comfy-cli's self-describing command surface') with a clear verb ('Return'), and frames the tool as a runtime way to learn the CLI's contract rather than a generic discovery operation. It distinguishes the tool from siblings by tying it to the specific 'comfy discover' wrapper.

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

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

It explicitly conveys when to use the tool ('at runtime instead of hard-coding it') and provides three concrete invocation modes with size and capability guidance. The warning that schemas_only=False is 'only for a client with a raised cap' effectively tells the agent when NOT to use that mode. This is unusually explicit usage guidance.

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

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

With no annotations provided, the description carries the full burden and delivers richly: it discloses that a present file proves nothing until status reads 'completed', that 'wait' returns a timeout payload that is NOT a failure, that 'cancel' stops a running transfer and its partial file, and that too-old comfy-cli returns an unsupported error instead of raising. These are exactly the behavioral traits an agent needs to interpret results correctly.

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. The first sentence front-loads the core purpose and the critical negative constraint. The action list is structured as a scannable bullet-like list with clear payload details. No filler or repetition of schema fields.

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

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

For a 3-parameter tool with no output schema and no annotations, the description covers all essential aspects: what each action returns, the timeout semantics, the required parameter, the error behavior for old comfy-cli, and the caveat about file presence. An agent has everything needed to call the tool correctly and interpret its results.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. It explains the meaning of action values ('status' default, 'wait' polls, 'cancel' stops), states that download_id is required for every action despite the schema marking it optional with a default, and clarifies that timeout_seconds only applies to 'wait' and is rejected elsewhere. This adds critical meaning beyond 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 description opens with a precise verb and resource: 'Track a transfer already started by download_model; does NOT start one.' This immediately distinguishes it from download_model and states the core action. It then enumerates the three action modes (status, wait, cancel) with specific behaviors, making the tool's purpose unmistakable.

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

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

The description explicitly says it does NOT start a transfer, which tells the agent when not to use it (when the goal is to initiate a download). It also names the sibling download_model as the tool that starts transfers, and explains the action-specific usage: download_id required for every action, timeout_seconds only for wait and rejected elsewhere. This is explicit 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?

No annotations are present, but the description fully carries the behavioral burden: it explains the transfer is submitted asynchronously, writes directly to the final path, returns a download_id, times out without error, and refuses remote targets. This goes well beyond basic expectations and prevents misuse.

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 long but tightly organized with Args, Returns, and Gotchas sections. Every sentence adds operational value, and the most critical distinctions and failure modes are front-loaded.

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

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

For a complex asynchronous tool with no annotations and no output schema, the description is fully complete: it covers parameters, return shapes for both wait modes, timeout semantics, remote-target refusal, and evidence-of-completion gotchas. An agent has everything needed to invoke and interpret the result 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 must compensate, and it does. It explains relative_path's workspace-relative 'models' requirement, wait's polling behavior, timeout_seconds' end-to-end budget and default rationale, and references url/filename in the wrapped command.

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: downloading a model file into the local ComfyUI models directory by URL. It also distinguishes itself from the catalog search tool by explicitly naming 'search_models' as the sibling it is not, so an agent can select it correctly.

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

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

Clearly says this is for known URLs and not hub search, and names the alternative 'search_models'. It also gives concrete routing cues such as the singular 'model' verb, the refusal behavior with remote ComfyUI, and the environment variable override, leaving little 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 fully discloses side effects: it never spends, but running the emitted graph does; it overwrites out_path in place without existence checks; and a comfy-cli lacking the spend gate bills silently. It also states it spends nothing and calls no partner API, providing complete behavioral context.

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 uses clear headings (Args, Returns, Gotchas) and a code chain example. Every sentence adds value: purpose, chain, parameter details, return format, and safety caveats. It is thorough yet tight, with front-loaded purpose and no filler.

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

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

Given no annotations and no output schema, the description provides everything an agent needs: what it does, how to call it with each parameter, the return shape, and critical gotchas. The chain example ties it to sibling tools. Nothing essential is missing for correct invocation.

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

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

Schema coverage is 0%, so the description must carry all parameter meaning. It does: model is constrained to five aliases (with routing advice), params mirrors partner_generate's validation and is optional even where the proxy requires it, and out_path points to the JSON file with an overwrite warning. This fully compensates for the schema's lack of description.

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

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

The description opens with a precise verb+resource: 'Write a runnable workflow that drives a partner model's NODE on LOCAL ComfyUI.' It clearly identifies the tool's function (emit a workflow graph) and distinguishes it from siblings by noting that non-listed models route to partner_generate. The chain example further clarifies the role.

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 explicit when-to-use guidance: it names the alternative partner_generate for models outside the five listed, and explains the full chain (emit → run_workflow → fetch_outputs), including that billing occurs at run_workflow, not at emit. It also warns against assuming the absence of confirm_spend means safety, which is a clear usage caveat.

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

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

With no annotations provided, the description carries full responsibility for disclosing behavior, and it does so thoroughly. It explains the url_only flag (emits URLs without downloading), the inline_images flag (returns base64 content while preserving on-disk copies), the return structure (metadata first, then capped image files), and the remote-job mechanism (state file keyed by prompt_id). It also discloses failure mode (download_job_not_found). No contradictions 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?

The description is moderately long but every sentence adds critical information: the core action, wrapper command, remote handling, inline image behavior, and return caps. It is front-loaded with the primary purpose and then layers details. Slight verbosity is justified by the tool's complexity.

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

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

For a tool with no annotations and no output schema, the description covers all essential aspects: the return format (metadata first, then image files), the caps on inline images, the behavior for remote jobs, and the failure condition. It leaves no critical gap an agent would need to call the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the two optional flags (url_only and inline_images) with concrete behavior, and implicitly clarifies prompt_id and out_dir through the main sentence. The required parameters are self-explanatory, so the description adds value where needed without over-explaining.

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

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

The description opens with a clear, specific action: 'Download a completed job's output files into out_dir.' It names the verb, resource, and destination, and differentiates from sibling tools by specifying 'completed job' and wrapping the comfy download command. This leaves no ambiguity about what the tool accomplishes.

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 context on when the tool works, including for jobs run on a remote machine, and specifies a limitation: a prompt_id never submitted on this machine will fail. However, it does not explicitly contrast this with alternative tools (e.g., generic 'download' or 'download_model'), so the when-not-to-use guidance is implied rather than stated.

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

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

With no annotations, the description carries the full burden. It discloses caching (24h TTL, refresh command), that it is not read from local install, the TOCTOU risk with shared out_path, the semantics of check_local and how to read the returned local_check block, and the difference between checked and unchecked states. This is thorough and beyond what the schema alone provides.

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

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

The description is long but structured with a summary, an example, Args, and Gotchas sections. Every sentence adds value—no redundancy. It is front-loaded with the core purpose and then elaborates. It is slightly dense but appropriate for the tool's complexity.

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

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

For a tool with 3 parameters, no output schema, and no annotations, the description is remarkably complete: it explains the return structure, the local check behavior, caching, freshness, and alternatives. An agent has everything needed to call it correctly and interpret the result. No obvious gaps remain.

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

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

Schema description coverage is 0%, so the description must compensate. It explains out_path (user-write-only, shared-path TOCTOU risk) and check_local (default true, meaning, and how to interpret the result). The name parameter is not described but is self-evident from the wrapped command; the two parameters with meaningful nuance are fully 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 verb-resource pair: 'Write a template's runnable workflow JSON to out_path; report if it can run here.' It then names the wrapped command (comfy templates fetch) and explains the return value, distinguishing its role in the on-ramp from siblings like get_template, search_templates, and validate_workflow.

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

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

Provides explicit usage context: it completes the on-ramp, includes a code snippet showing when to call run_workflow versus validate_workflow, and warns that a bare validate_workflow is weaker than local_check. It also states that step 4 is not optional, effectively telling the agent when this tool is required and when to defer to validate_workflow.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that the operation is NOT IMMEDIATE, never destructive, does not interrupt running jobs, returns only the requested action rather than a measurement, and is not diverted by COMFYUI_URL/COMFYUI_HOST.

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?

Though longer than average, every sentence earns its place: the first line states purpose, the Args section resolves ambiguous parameter combinations, and the caveats section prevents misuse. The structure is front-loaded and scannable with bolded callouts.

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

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

Given no annotations and no output schema, the description is complete for correct invocation. It covers what the tool does, what it does not do, parameter semantics, return semantics, environment behavior, and relevant sibling alternatives.

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

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

Schema coverage is 0%, so the description must explain the parameters, and it does. It details unload_models default behavior, the deliberate no-op combination, the semantics of free_memory=None following unload_models, and the rejected True-with-unload_models=False case.

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

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

The description opens with a specific verb and resource: 'unload models / reset its executor cache' via local ComfyUI. It distinguishes itself from related tools by explicitly referencing system_stats for before/after and job(action='cancel') for interruption.

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

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

The description clearly states when to use this tool and when not to: it is not immediate)Skip, cannot interrupt a running job, and job(action='cancel') is the alternative for stopping. It also advises pairing with system_stats for measurements, giving the agent actionable routing 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 present, the description carries the full behavioral burden, and it delivers: it reveals the execution path (ComfyUI run-template, same run path as run_workflow), the local-vs-remote behavior via COMFYUI_URL/COMFYUI_HOST and 'never Cloud', the cost model ('Always FREE'), the synchronous/asynchronous behavior of wait, and the effect of timeout_seconds. It even notes checkpoint must be pre-installed on the machine that runs the job.

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 clear one-line purpose, then uses compact labeled sections (Args, Returns, Gotchas). Every sentence carries information — environment variables, parameter effects, routing guidance, and return shape — without 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 tool with no output schema and no annotations, the description covers everything needed to invoke it correctly: the return envelope (prompt_id + outputs), the alternative routing to sibling tools, the model prerequisite, sync/async semantics, and environment overrides. No meaningful gap remains for correct usage.

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

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

Schema description coverage is 0%, so the description must compensate for the bare schema. It does: the Args section gives the meaning and interaction of checkpoint, wait, and timeout_seconds, including how wait changes timeout behavior and how to poll with job(action='status'). This fully bridges 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?

Opens with a specific verb and resource ('Generate an image from a text prompt') and immediately brands itself as 'the fast on-ramp.' It distinguishes itself from siblings by naming run_workflow and partner_generate and stating it runs ComfyUI's default SD1.5 template, so an agent can tell exactly what it does and what it is not.

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

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

Explicitly tells the agent when to use this tool versus alternatives: use partner_generate for paid PARTNER models, and use search_templates -> fetch_template -> run_workflow for chosen templates or hand-authored workflows. It also explains the wait=True/False behavior so the agent can choose between synchronous and polling-based consumption.

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 fully discloses behavior: it wraps 'comfy logs --tail <tail>', reads a persisted stdout/stderr file, returns a structured object {lines, path, truncated}, returns errors as data (not raised exceptions), and reports trust signals (source, port_mismatch). This is rich, transparent disclosure that goes beyond any annotation would offer.

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

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

The description is well-structured: a lead sentence stating purpose, followed by operational details, parameter guidance, and edge-case handling. It is a bit long but every sentence adds value—no filler. The port disambiguation and trust-signal warnings are essential. Structure is logical and front-loaded.

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

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

The description covers the return object, error handling (returns data not raised error), port disambiguation, and trust signals. The only minor omission is an explicit explanation of the tail parameter and what 'truncated' means, but overall it is sufficient for a tool with no annotations or output schema. It gives an agent everything needed to call it correctly in most scenarios.

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 thoroughly explains the port parameter, including its purpose and when to pass it. However, the tail parameter is only mentioned via the wrapped command ('--tail <tail>') without a clear definition of what it controls (number of lines). Given 0% schema coverage, this is a partial gap—port is well covered, tail is not explicitly defined.

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

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

The description clearly states the tool's function: 'Return the tail of the LOCAL background ComfyUI's captured log file.' It also distinguishes it from siblings by noting it's 'the only way to see a detached server's output,' which sets it apart from any other log-related tool. The verb 'return' and resource 'log file' are specific and unambiguous.

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

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

Provides explicit usage guidance for the port parameter: 'Pass it whenever more than one ComfyUI/port has run here, and always after a crash.' It also advises retrying with an explicit port when trust signals (source, port_mismatch) indicate doubt. While it doesn't name alternative tools, the guidance for correct invocation is clear and actionable.

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

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

With no annotations provided, the description carries the full burden and delivers richly: it discloses 24h caching with a version floor, that it does NOT read from the local install, the conditional absence of local_check on drifted payloads, and the semantic difference between checked:false (no runnable key, read via .get()) and checked:true/runnable:false. This is exemplary behavioral disclosure beyond any structured field.

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 longer than average, but every sentence carries load-bearing information about conditional keys, caching, and check semantics. The structure — purpose line, CLI wrapper, arg breakdown, then conditional/caching caveats — front-loads the core purpose and organizes complexity well. Slightly dense, but justified by the tool's conditional behavior.

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

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

Given no output schema and no annotations, the description covers what an agent needs to invoke correctly: response conditions (local_check presence/absence), checked/runnable semantics, caching behavior, and the relationship to fetch_template. The main gap is the overall response shape beyond local_check ('details/schema' is unspecified), but the invocation-critical behavior is fully covered.

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

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

Schema description coverage is 0%, so the description must compensate. It thoroughly explains check_local: what true adds, what checked:true/false mean, what false skips, and the conditional-key caveat. The name parameter is only implied by 'Show one template's details/schema,' but its meaning is self-evident from the schema's string type and required status.

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 concrete verb+resource statement: 'Show one template's details/schema, and whether your install can run it.' It further differentiates from the sibling fetch_template by positioning itself as 'Step 2 of the on-ramp: inspect before fetch_template(name, out_path) writes the runnable JSON.' An agent can distinguish this from fetch_template and run_template 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 gives explicit workflow placement — inspect with this tool before calling fetch_template — and explains when the local check must happen ('the check still must happen before the run'). It does not enumerate exclusions or alternative conditions (e.g., when to skip straight to run_template), but the on-ramp sequencing provides clear enough usage context.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that the tool runs third-party code, asks first, does NOT restart ComfyUI (restart_required is true when anything installs), requires ComfyUI-Manager, and that per-pack failures are reported in 'failed' rather than raised. It also explains the fallback behavior of confirm_install on non-elicitation clients.

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 front-loads a one-line summary, then uses clear 'Args:', 'Returns:', and 'Gotchas:' headers to organize nuanced information. Every section adds essential operational detail, and the formatting makes the long content scannable. There is minimal redundancy; each gotcha addresses a distinct failure mode.

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, no output schema, and no annotations, the description covers all necessary aspects: input formats, required ComfyUI-Manager setup, return dictionary structure, error keys ('unsupported', 'failed'), restart behavior, and how to verify success. It enables an agent to call the tool correctly and interpret results without needing additional documentation.

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 provides detailed semantics for both parameters: 'names' is defined as registry pack ids from nodes/workflow_deps, with explicit exclusions (class names, git URLs, @version pins), and 'confirm_install' is explained as a fallback that should only be True after user agreement, with prompt behavior depending on client support.

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 ('Install custom node packs into the LOCAL ComfyUI') and immediately distinguishes itself from siblings by clarifying input types ('registry pack ids ... never a node CLASS name') and pointing to workflow_deps for conversion. It also notes that git URLs and version pins are refused, which differentiates this tool from direct terminal installs. This clearly identifies the tool's purpose among the sibling set.

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

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

It explicitly states the correct input ('Feed it registry pack ids ... from nodes / workflow_deps'), what to avoid ('never a node CLASS name', 'a git URL or an @version pin is refused'), and provides alternatives: 'convert it with workflow_deps first' and 'run comfy node install in a terminal for those.' It also explains when confirm_install should be True, giving clear conditional usage.

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

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

With no annotations provided, the description carries the full burden and excels: it discloses that error returns None when healthy, that wait's timeout is a non-failure signal, that watch may return null progress due to comfy-cli 1.15.0 limitations, the error_code naming scheme for crashes, and the node_failure vs server_died distinction. This is exemplary behavioral disclosure.

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 long, but its density is justified by the multi-action surface — each of six actions earns its dedicated block with behavior and edge cases. The opening line front-loads the overall purpose, and formatting with bulleted actions aids scannability. Minor redundancy (defaults repeated) keeps it from a 5.

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

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

For a complex multi-action tool with no output schema and no annotations, the description covers everything needed to call it correctly: parameter requirements, per-action return shapes (timed_out dict, status snapshots, error fields), timeouts, ceilings, and version caveats. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 0%, but the description fully compensates: it enumerates every valid action value for the 'action' parameter with its effect, clarifies that prompt_id is required for all actions except 'queue', and specifies timeout_seconds applies only to 'wait'/'watch' — even noting that unused params are rejected. This exceeds what the bare schema would convey.

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

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

Description states a specific family of verbs (Inspect, wait on, watch, cancel) applied to a clear resource (submitted job), plus the 'one action per call' constraint. It maps six distinct actions to underlying CLI commands, making the tool's scope unambiguous and distinguishable from the workflow/launch siblings in context.

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

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

The description instructs when each action is appropriate: 'safe to call speculatively' for error, wait vs watch polling behaviors with defaults/ceilings, and crash handling that points to a sibling ('check get_logs before relaunching'). It lacks explicit 'use X instead of this' exclusions, but the get_logs referral and per-action semantics give clear contextual guidance.

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

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

With no annotations, the description carries the full burden, and it exceeds it. It discloses that the command wraps 'comfy launch --background', records the pid, prints text with no JSON envelope, returns a synthesized {'ok': True, ...} object, and explains the security implications of non-loopback --listen and --enable-cors-header.

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: summary, mechanics, prerequisite, safety warning, and output format are each in clear sections. The most critical caveats about network exposure and user confirmation are highlighted and front-loaded appropriately.

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, lack of annotations, and lack of an output schema, this description is remarkably complete. It covers startup semantics, failure mode, process management, security behavior, elicitation behavior, and return format — everything an agent needs to call it correctly and safely.

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 fully compensates. It explains that extra_args are forwarded after a '--' separator, and it details confirm_network_exposure semantics: when it triggers an elicitation, when it is a fallback, and when it must not be 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 opens with a specific verb and resource: 'Start the LOCAL ComfyUI server, detached, and return once it is up.' It clearly distinguishes launch_comfyui from siblings like stop_comfyui, restart_comfyui, and server_info by emphasizing 'LOCAL', 'detached', and the return-once-ready behavior.

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 explicit usage context: call server_info first, because a second launch fails on the port, and notes that stop_comfyui is the paired shutdown tool. It also provides precise conditional guidance for network-exposing flags, telling the agent when confirmation is required and when confirm_network_exposure may be used as a fallback.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the list is PINNED, a curated allowlist in the installed comfy-cli's code, and explains that absence is not evidence of nonexistence—directing the fix to an upgrade rather than a refresh. It also notes that one row can represent a model family, which is critical to avoid misinterpreting the output. These are non-obvious behavioral traits disclosed beyond the basic listing action.

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

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

The description is structured with clear sections (Args, Returns, Freshness) and front-loaded with the primary purpose. It is long but each sentence adds value—no fluff. The only minor nit is that the freshness paragraph could be tightened, but overall it is well-organized and scannable.

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

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

With no output schema, the description specifies the exact return structure ({total, shown, offset, filters, models} and each model's fields). It also mentions the sibling partner_model_schema for parameter details, and explains the pinned allowlist behavior. For a tool with five optional parameters, no annotations, and no output schema, the description covers all essential aspects an agent would need to call it correctly and interpret results.

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

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

Schema description coverage is 0%, so the description must compensate. It does: it explains style/partner/query as filters forwarded to comfy-cli with exact/substring matching, and notes that an unfiltered call reveals the real category strings. For limit/offset, it gives defaults (100, 0), the cap (200), and pagination logic (page while shown < total). Every parameter is meaningfully clarified beyond the bare schema definitions.

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 hosted PARTNER models partner_generate can run.' It distinguishes itself from siblings by noting it is 'the ONLY source of the partner alias catalog' and explicitly contrasts with nodes/search_templates, which read the local install. This leaves no ambiguity about what the tool does or how it differs from related 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 on when to use the tool—when you need the list of hosted partner models for partner_generate. It also gives behavioral guidance on filtering and pagination, and advises following with partner_model_schema. It indirectly distinguishes from nodes/search_templates by noting they read the local install, but does not explicitly state 'use this instead of X when Y.' Still, the guidance is strong enough to route an agent appropriately.

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

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

With no annotations present, the description carries the full burden and excels: it discloses the wrapped command, the note types surfaced, the untrusted-data warning, the exact return shape, the normal 'count: 0' case, and graceful degradation on older comfy-cli versions. This far exceeds what structured fields 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 longer than average, but every sentence adds meaningful operational value: purpose, wrapping, differentiators, rejection behavior, security handling, return shape, and degradation. It is front-loaded with the core purpose and the alternative 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?

Despite lacking an output schema, the description fully documents the return value ('{"workflow", "count", "notes"}') and the edge cases of zero notes and unsupported CLI versions. For a single-parameter listing tool, nothing an agent needs to call it correctly is missing.

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

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

The schema only declares workflow_path as a required string with 0% coverage, so the description must compensate. It does: 'comfy workflow notes <path>' clarifies the parameter is a path, and 'frontend-format workflow' plus the API-format rejection narrows what kind of path is valid. Minor syntax details like absolute vs relative paths are not specified, but the core semantics are clear.

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

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

The description opens with a specific verb and resource: 'List the documentation notes a frontend-format workflow carries.' It also differentiates itself from the sibling list_workflow_slots by stating these notes are 'not included' there, so an agent can distinguish the tools clearly.

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 explicit context: it needs no running ComfyUI, warns that an API-format export is rejected, and routes the agent to 're-fetch with fetch_template' in that case. It also identifies list_workflow_slots as the alternative that does not include these notes.

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 present, the description carries the full disclosure burden and meets it: it reveals this is a read wrapper over `comfy workflow slots <path>`, defines the slot/ADDR model, documents the A/B.name vs A.name addressing scheme, notes that both kinds come back in an `address` field, and explicitly excludes Note/MarkdownNote text. This is rich behavioral context well beyond a bare 'list' statement.

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 crisp one-line purpose, followed by four sentences that each earn their place: the ADDR explanation, the addressing scheme with a concrete example, and the exclusion note. No filler or restatement of the schema; the density is justified by the genuinely non-obvious address semantics.

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

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

There is no output schema, so the description must convey what the tool returns, and it does: slots carry a stable ADDR plus current value, both kinds of addresses come back in an `address` field. Combined with the pointed exclusion and sibling routing, an agent has everything needed to call this tool and correctly consume its output with set_workflow_slot/vary_workflow.

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

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

Schema description coverage is 0%, so the description must compensate. It maps the single workflow_path parameter to the CLI `<path>` via 'Wraps comfy workflow slots <path>' and adds that the path points to a frontend-format workflow, which gives the agent useful context beyond the bare 'Workflow Path' title. It could be more explicit about path format requirements, but for a single self-explanatory parameter this is solid compensation.

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 states a specific verb and resource ('List the agent-tweakable slots a frontend-format workflow exposes') and distinguishes the tool from siblings by naming list_workflow_notes as the alternative for note text and set_workflow_slot/vary_workflow as the consumers of slot ADDRs. An agent can tell exactly what this tool does and is not 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?

The description gives explicit routing guidance: use list_workflow_notes for Note/MarkdownNote text, pass a slot's ADDR to set_workflow_slot/vary_workflow to change it, and the stated use case ('an agent can see what a template exposes without hand-reading the JSON') tells an agent when to choose this tool. Exclusions and alternatives are both explicit.

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

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

With no annotations present, the description carries the full burden and does so well: it declares the operation read-only, states no installation or changes occur, describes the returned row statuses, and warns about an error/unsupported payload on older comfy-cli versions.

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

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

The description is front-loaded with the core purpose, then uses terse labeled sections for context and args. Every sentence contributes either scope, usage guidance, parameter meaning, or output behavior with no filler.

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

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

Given the simple two-optional-parameter surface and no output schema, the description covers the essential context: what the tool reads, how parameters affect scope, the shape of per-row statuses, and a possible error return. An agent has enough to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does robustly: 'pack' is explained as an installed pack name with omission behavior, and 'registry_id' is explained as a not-yet-installed registry pack pre-check, including the additive behavior when both are supplied.

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

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

The description clearly states the verb 'Report' and a specific resource: a custom node pack's Python dependency requirements versus the installed venv. It also explicitly contrasts itself with the sibling tool 'nodes', making its unique role unambiguous.

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

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

The description provides solid context by explaining the difference from 'nodes' (live object_info vs pip list) and stating that nothing is installed or changed. It does not explicitly mention alternatives like 'workflow_deps' or 'install_node', but the read-only scope and parameter guidance are clear enough for most selection cases.

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 exceeds expectations by revealing that the tool reads live from object_info every call, that close-match results are guesses (not certain matches), that a minimum comfy-cli version is required, and that invalid parameter/action combinations are rejected.

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 long but justified by the tool's complexity. It is well-structured with a purpose-led opening, an action-by-action bulleted list, a separate parameter-constraint paragraph, and a freshness note. Every sentence carries useful information and none is filler.

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

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

For a 13-parameter tool with no annotations and no output schema, the description addresses action semantics, parameter applicability, defaults, and edge behaviors. However, return values are only sketched ('full input/output schema', 'filtered browse', 'connection types by connectivity'); a bit more precision on response shape would make it fully complete, though it is enough for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It maps each parameter to the specific actions where it is valid, explains the meaning of each action (search token-matching, upstream/downstream direction, path chains), and gives defaults (action=search, max_depth=6, max_paths=10). This adds substantial semantic value beyond the raw 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 first sentence states a specific set of verbs and a resource: 'Search, inspect, filter, or graph-walk node classes in the LOCAL live catalog.' This clearly distinguishes the tool from siblings like search_templates or search_models by scope (node classes) and locality (local live catalog), without needing to name alternatives.

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

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

The description gives thorough guidance on when to use each action mode, including defaults, valid parameter combinations, and version requirements. It provides clear context but does not explicitly name alternative sibling tools or state when not to use this tool in favor of another, so it falls short of a 5.

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

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

There are no annotations, so the description carries the full behavioral burden. It fully discloses that the call ALWAYS spends credits, runs remotely on PARTNER's infrastructure, fails closed when no consent source is available, and returns saved_paths verbatim from comfy-cli. This is unusually transparent about side effects and failure behavior.

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

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

The description is long but every sentence earns its place: headline warning, local-vs-remote distinction, parameter semantics, and gotchas are all tightly packed without repetition. The front-loaded 'SPENDS CREDITS' immediately signals the most critical behavioral fact.

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 credit-spending, remote-execution tool with no annotations and no output schema, the description covers nearly all critical context: purpose, consent, spend, fail-closed behavior, path templating, and saved_paths. The only notable gap is timeout_seconds, which is undocumented, and the return payload beyond saved_paths is not described.

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 substantially by explaining params (model's own inputs forwarded verbatim), confirm_spend (real user consent vs fallback), and out_path (template with placeholders). However, it does not explain timeout_seconds at all, and the model parameter itself only gains meaning through the intro text, not a dedicated parameter explanation.

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

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

The description states a specific action ('Run a hosted PARTNER model') and names the model families it covers. It also explicitly differentiates from local execution by saying 'For local execution, use emit_partner_workflow -> run_workflow -> fetch_outputs instead', which lets an agent pick the right tool 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 gives explicit when-to-use instructions: hosted PARTNER models versus local execution, and even redirects to sibling tools for the local path. It also tells agents to discover model parameters with list_partner_models() and partner_model_schema(model) rather than nodes/search_templates, so the selection and invocation context is clearly mapped.

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

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

There are no annotations, so the description must carry the full behavioral burden, and it does. It discloses that the tool makes no partner API call and spends nothing, that the data is PINNED from a vendored spec with a documented refresh mechanism, and that a miss should not be reported as nonexistent. It also describes the return envelope and caveats about enum granularity versus list_partner_models, which gives the agent accurate expectations about behavior.

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

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

The description is front-loaded with the core purpose and then adds each necessary layer: wrapper command, side-effect-free guarantee, return structure, freshness behavior, and failure-handling guidance. Despite the length, every sentence earns its place, and there is no tautology or filler. The structure makes a complex tool easy to parse.

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

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

Given there is no output schema, no annotations, and zero schema description coverage, the description supplies all critical context: what the tool returns (including nested param fields), how to interpret 'binary' type, where the model values come from, how stale the data can be, how to refresh it, and how to handle a miss. An agent has everything needed to decide when to call it and how to interpret the result.

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

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

Schema coverage is 0%, so the description fully compensates. It defines the only parameter, 'model', as an alias from list_partner_models, which is essential operational knowledge: the agent must obtain the value from that sibling tool. It also clarifies that this alias identifies a partner model variant, so the parameter semantics go well beyond the bare schema type.

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 states a specific verb ('Show') and resource ('one partner model's callable parameters') and explicitly frames the output as 'the input to partner_generate'. It distinguishes this tool from partner_generate (which consumes the schema) and list_partner_models (which supplies the model alias), so an agent can immediately tell where it fits among 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 description clearly implies when to use this tool: to inspect the callable parameters for a model from list_partner_models before calling partner_generate. It also defines a boundary by stating 'Reads the spec only — no partner API call, no spend,' which tells the agent this is the safe, non-side-effect way to learn parameter structure. It does not explicitly say 'use this instead of partner_generate for schema introspection,' but the context is strong enough to route an agent correctly.

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 and does so impressively: it discloses side effects (creates `comfy.yaml` + dirs), error behavior (`project_already_exists`), cwd behavior, the one-time read of `COMFY_PROJECT`, and routing details. This is far beyond a basic one-line 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 dense but well-organized: purpose first, then action mapping, then environment/cwd caveats, then routing. Every sentence carries relevant information, though the final routing note is slightly cryptic and may require domain knowledge to interpret.

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 and the absence of annotations or an output schema, the description covers setup, side effects, errors, and environment dependencies thoroughly. The only notable gap is the lack of any description of the return value or output format, which an agent may need to interpret results after calling.

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 only lists an `action` property with a default and no descriptions, so the description must compensate. It fully explains the two meaningful values (`'status'` and `'init'`), their effects, and the recommended order of calling. This is exactly what an agent needs to invoke the parameter correctly.

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 'Report or create the operator-anchored comfy-cli project', giving a specific verb and resource. It further disambiguates the action parameter by mapping 'status' and 'init' to concrete CLI commands, so an agent knows exactly what this tool does and how it differs from other MCP tools.

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

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

The description gives clear context and a sequencing hint: try `action='status'` first before `'init'`, and explains the `COMFY_PROJECT` environment variable and cwd caveat. It does not name explicit alternatives or when-not-to-use conditions, but no close sibling exists among the listed tools.

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

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

With no annotations, the description carries full burden. It discloses the stop-then-launch sequence, extra_args forwarding, confirmation prompts, kill behavior, concurrency refusal, and remote target skip. This is exceptionally 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 detailed but each sentence adds a distinct behavioral fact. It is front-loaded with the composed operation and then covers edge cases. No redundancy or fluff.

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

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

Covers purpose, error handling, concurrency, network exposure, untracked port, parameters, and return status. For a tool with no annotations and no output schema, this is complete and leaves nothing an agent needs to call it correctly.

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

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

Schema coverage is 0%, but the description explains all three parameters: extra_args forward to the new server, confirm_network_exposure is the no-prompt fallback, and confirm_kill_untracked defaults to False and kills nothing. Fully compensates 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?

The description clearly states the tool restarts the LOCAL ComfyUI server and explicitly composes stop_comfyui + launch_comfyui, distinguishing it from sibling tools. The verb-resource pair is specific and unambiguous.

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

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

It explains the composition and mentions the network-exposure confirmation and untracked port handling, but does not explicitly name when to prefer this over the siblings (e.g., 'use launch_comfyui for a fresh start'). However, the composition statement makes the intended use obvious, so this is clear enough.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses that some templates contain partner-API paid nodes that spend the account's Comfy credits, that a paid template fails CLOSED with spend_consent_required and spends nothing without consent, that wait=False submits --async and returns a prompt_id, and that a missing model surfaces as a per-node error. No contradiction with annotations (none supplied).

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 a one-line purpose, then cleanly organized into Args and Gotchas sections, with nearly every sentence carrying non-obvious information. It is slightly redundant — the fail-closed consent point appears both in confirm_spend and in the first Gotcha — but the length is proportionate to the tool's risk profile (credit spend, async execution, slot addressing).

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 high-complexity tool with zero annotations and no output schema, the description covers the execution pipeline, consent gating, sync vs async return contracts, timeout behavior, and failure modes. The one real gap: it says wait=False returns 'a prompt_id to poll' but never names the sibling that would consume it (e.g., job or fetch_outputs), which would fully close the loop for an agent.

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

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

Schema description coverage is 0%, so the description must carry the meaning for all five parameters, and it does: name via the CLI form, params with concrete slot-addressing syntax ("6.text", "prompt", "A/B.name" for subgraph interiors), confirm_spend with a strict consent rule and fail-closed behavior, wait with sync-vs-async return contracts, and timeout_seconds with its default and wall-clock meaning. This goes far beyond the bare schema titles 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 opening line states a specific verb and resource — 'Run a gallery template' — and spells out the internal pipeline (fetch, fill params, execute). It further distinguishes itself from siblings by naming itself as the one-command alternative to the search_templates -> fetch_template -> run_workflow chain, so an agent can differentiate it without opening other 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?

Names the alternative multi-step pipeline explicitly and gives strong conditional guidance: wait=False is 'preferred for long (video) runs', and confirm_spend is only to be set when the user has actually agreed, never to clear an error. However, it never states an explicit when-not case, such as 'use fetch_template when you need to inspect or modify slots before running', so the exclusion is implied rather than stated.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses blocking vs submit-and-return behavior, the unreliability of progress notifications, absence of per-step events in comfy-cli 1.15.0, timeout behavior, credit-spend gating with a fail-closed mode, potential OOM crashes surfacing as connection loss, and automatic retries for partner-API transient failures.

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 long but densely structured with an opening summary, parameter explanations, and a 'Gotchas' section. Each section earns its place and adds operational value; the front-loaded purpose sentence lets an agent quickly determine whether this is the right tool.

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

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

For a complex, potentially side-effecting workflow runner with no annotations and no output schema, the description is remarkably complete. It covers target environment, accepted file formats, parameter behavior, progress polling strategy, spend consent, crash behavior, credential requirements, and retry semantics. An agent has enough context to invoke correctly and to route long-running or paid workflows appropriately.

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 fully compensate. It explains `wait`'s blocking behavior and return value, `timeout_seconds`'s scope and default rationale, `confirm_spend`'s gating semantics, and the workflow file formats accepted. Every parameter is given meaning beyond its bare schema type.

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 ComfyUI workflow JSON on the ComfyUI this server targets.' It further clarifies scope by noting which server is targeted and that it wraps `comfy run --workflow`, making the tool's role unmistakable relative to sibling tools like run_template or generate_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 explicitly gives when-to-use guidance: use `wait=False` plus `job(action='wait')`/`job(action='watch')` for longer runs, poll `job(action='status')` for progress, and set `confirm_spend=True` only with actual user consent. It also clarifies that paid workflows fail closed without consent, giving a clear boundary for when the tool is and isn't safe to invoke.

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 to carry safety or behavior, the description fully discloses live disk reads, filename-only results with no registry metadata, mode-dependent response shapes, query token normalization, and version-dependent substring matching. It also explains the operational consequence of false negatives, which is exactly the behavioral context an agent needs.

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 text is dense but every sentence earns its place given the mode-dependent complexitycars. It is front-loaded with the core purpose, uses clear section labels, and avoids fluff while covering version, response shape, and freshness caveats.

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

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

Given no output schema and no annotations, the description fully covers return shapes per mode, version constraints, matching semantics, and what absence of results means. Nothing an agent needs to invoke this tool correctly or interpret its output is missing.

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

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

Schema description coverage is 0%, but the description compensates thoroughly by explaining how query tokens are matched, how folder restricts the search, and how the two optional parameters interact to select modes. Concrete examples and caveats such as 'sdxl base' and folder='loras'/'vae' make both parameters semantically 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 explicitly states the tool searches/lists model files on the local ComfyUI installro, defines three distinct modes with exact CLI equivalents, and clearly differentiates it from sibling tools like search_templates and download_model. The verb and resource are specific and immediately actionable.

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

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

It provides explicit mode-selection rules (query first, then folder, then list-folders), version-specific behavior guidance, and names download_model as the alternative when a model is genuinely absent. It also advises re-checking with folder='loras'/'vae' before concluding non-existence, which is a precise usage directive.

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

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

With no annotations provided, the description carries the full burden and delivers extensively: it discloses the return shape, paid API-tag credit implications, the run_template CLOSED failure unless confirm_spend, two-pass query matching, word anchoring, unmatched_query_words, 24-hour cache freshness, and that it is NOT read from the local install. There is no contradiction with annotations because 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?

The description is long but densely organized with Args and workflow sections; the most important facts are front-loaded, and every sentence adds meaningful behavioral or parameter detail. Given 8 parameters and zero schema descriptions, the length is justified.

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

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

There is no output schema, so the explicit return shape and row projection are necessary and provided. Freshness, parameter semantics, API-caveat guidance, and downstream routing to get_template/fetch_template make the description complete 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%, but the description documents every parameter in detail: query's phrase/all-words behavior, tag/type/model/provider forwarded filters, exclude_api semantics, and limit/offset pagination with a 200 cap. This far exceeds what the bare schema provides.

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

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

The description opens with a specific verb and resource: 'Search the built-in ComfyUI workflow-template gallery.' It further distinguishes itself by naming the wrapped command (`comfy templates ls`), the projected row fields, and the derived `api` boolean, clearly separating it from siblings like get_template, fetch_template, and run_template.

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 places the tool in a clear workflow: 'Step 1: pick a name, inspect with get_template, then fetch_template,' and explains downstream run_template behavior for paid API templates. It does not explicitly enumerate when to prefer this over search_models or when not to use it, but the gallery-scoped workflow context is strong.

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

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

No annotations are provided, so the description carries the full burden, and it excels. It discloses that the local install is always returned even with a remote configured, that `hardware` is conditional on the installed comfy-cli reporting it, that `compatibility` raises before returning on hard incompatibility, and that `comfy_target` is only present for remote configurations. It even clarifies that `{"unsupported": true}` in freshness means nothing is broken, preventing misinterpretation.

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?

Though lengthy, the description is meticulously structured with a summary line followed by a bullet-like 'Returns' section breaking down each field with its conditions. Every sentence carries actionable information—no filler. The critical 'call this first' instruction is front-loaded, and the conditional field explanations are organized logically for an agent to parse.

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

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

With no output schema and no annotations, the description must fully specify what the agent can expect, and it does. It covers every return field, under what conditions each appears, and how to interpret them (e.g., freshness update guidance, unsupported meaning). It also explains the tool's relation to remote configurations without probing them. Nothing needed for correct invocation or interpretation is missing.

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

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

The tool has zero parameters and the schema is empty with 100% coverage, so there is nothing for the description to explain about parameters. Per the baseline for 0-param tools, a score of 4 is appropriate; the description need not add parameter detail and it does not, which is correct.

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 precise verb+resource statement: 'Report the local ComfyUI/comfy-cli environment and verify compatibility.' It also notes it wraps `comfy env`, which clearly identifies the underlying operation. This distinguishes it from sibling tools like system_stats or get_logs by positioning it as the environment/version probe, not a runtime stats logger.

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

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

Explicitly instructs 'Call this first to confirm a local ComfyUI is up before running a workflow,' giving a clear entry point. It also provides conditional guidance: check for `hardware` and consult server instructions, and if `freshness` shows outdated core/packs, tell the user to update first. This gives both when-to-use and what-to-do-with-output guidance, leaving no ambiguity about its role.

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

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

No annotations are provided, so the description carries the full burden. It discloses the non-destructive default (stdout=True returns modified workflow rather than writing in place), the destructive alternative (stdout=False writes back), the type-preservation behavior, and the coercion behavior of the string form. This is rich behavioral context beyond what the schema provides.

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

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

The description is well-structured with a clear opening sentence, a wrapper note, a bulleted list for the two override forms, and a final behavioral note. Every sentence earns its place; the formatting makes the two forms and their trade-offs scannable.

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

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

For a 3-parameter tool with no output schema and no annotations, the description covers the purpose, the two input forms, the type semantics, the destructive/non-destructive behavior, and the relationship to sibling tools. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the meaning of overrides (both structured and string forms), the address format (feed list_workflow_slots' address in), the value type semantics, and the stdout parameter's effect. The description adds substantial meaning beyond the bare schema field 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 states a specific verb ('Set'), a specific resource ('slot values on a frontend-format workflow'), and the underlying CLI wrapper. It also names the parameterize step of the template on-ramp and contrasts with hand-editing JSON, which clearly distinguishes it from sibling tools like list_workflow_slots and run_workflow.

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

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

The description explicitly explains when to use this tool (the parameterize step of the template on-ramp: change prompt/seed/steps/model without hand-editing JSON) and gives concrete guidance on the two override forms, including when to prefer structured vs string. It also explains the stdout=True vs False behavior, which is a key usage decision.

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

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

With no annotations, the description carries full burden. It discloses the output format (no JSON envelope), the synthesized success dict, the lock-sharing behavior, and the error condition. It also reveals the destructive action of killing the recorded pid, which is a significant behavioral trait.

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 moderately long but every sentence adds value: action, ownership, output, concurrency. It is well-structured with a clear lead and a bullet point. It could be slightly more concise, but it avoids redundancy and front-loads the core purpose.

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

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

Given zero parameters, no output schema, and no annotations, the description covers all necessary aspects: what it does, limitations, error handling, concurrency behavior, and return format. An agent has everything needed to invoke it correctly.

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

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

There are zero parameters, so the baseline is 4. The description adds no parameter-specific information because none exist, but it does explain the wrapping of 'comfy stop' and ownership semantics, which provides context beyond the empty schema.

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

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

The description clearly states the specific action (stop), the resource (LOCAL ComfyUI server), and the scope (launched by comfy-cli). It distinguishes from sibling tools like launch_comfyui and restart_comfyui by explicitly noting ownership semantics and the inability to stop other servers.

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

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

The description explicitly states when the tool is NOT appropriate (server started by desktop app or by hand) and explains the concurrency constraint with launch/restart. It gives clear conditions for refusal and error behavior, leaving no ambiguity about usage scenarios.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it is exceptionally thorough. It flags the operation as DESTRUCTIVE, explains that it stashes uncommitted changes, moves the checkout, reinstalls dependencies, refuses while ComfyUI is running, requires per-call user consent, and shares a lock with update_comfyui. It also clarifies that restart_required is always True. This is strong behavioral transparency for a destructive operation.

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

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

The description is long but every section earns its place: purpose, wrapped operation, parameter semantics, canonical flow, gotchas, and return value. It is front-loaded with the destructive warning and the rollback purpose, and it uses clear formatting with headers and code blocks. Nothing is redundant or ornamental.

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

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

Despite having no output schema, the description discloses the return shape ('{"switched_to", "result", "restart_required": True}') and the fact that restart_required is always True. It also covers prerequisites, exclusions, locking behavior, and the canonical sequence involving sibling tools. For a destructive, state-changing operation, it is remarkably 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 must explain the parameters, and it does comprehensively. It enumerates valid version values ('nightly', 'latest', release tags with or without leading v) and states that anything else is refused before any subprocess runs. It also explains confirm_switch semantics in detail, including the no-prompt fallback and the requirement that it only be set when the user has actually agreed.

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: 'Move the LOCAL ComfyUI install to a specific version.' It also distinguishes itself from the sibling tool by explicitly stating that it is used to roll BACK while 'update_comfyui only moves forward.' This leaves no ambiguity about what the tool does or how it differs from related tools.

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

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

The description gives explicit guidance on when to use this tool versus alternatives ('Use to roll BACK — update_comfyui only moves forward'). It also provides a canonical flow ('stop_comfyui -> switch_comfyui_version -> launch_comfyui -> server_info') and clear gotchas such as refusing while ComfyUI is running and sharing update_comfyui's lock. An agent knows exactly when to call it and what prerequisites must be met.

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 present, the description carries the full burden and succeeds: it declares read-only safety, polling friendliness, near-verbatim forwarding, the exact returned device/system fields, and even the secret-bearing argv caveat. It also discloses the routing exception versus other tools.

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?

Every sentence adds operational value: what it reads, what it wraps, exact return fields, when to call it, and routing caveats. The paragraphs are front-loaded with purpose and followed by actionable warnings, with no filler.

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

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

Despite no output schema, the description spells out the devices/system response shape and the server_not_running failure mode. It also covers the edge case of COMFYUI_URL/COMFYUI_HOST being set and the need to resolve routing before gating a run, making the tool safely callable in realistic conditions.

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

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

The tool has zero parameters and 100% schema coverage, so parameter-meaning additions are unnecessary; baseline 4 applies. The description uses the space to explain what the response contains rather than parameter semantics.

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

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

Description opens with a precise verb and resource ('Read the live local ComfyUI's VRAM per device and system RAM') and names the underlying endpoint (GET /system_stats). It also differentiates itself from sibling run/job tools by explicitly stating it is not diverted by COMFYUI_URL/COMFYUI_HOST.

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

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

It gives a direct call trigger ('Call BEFORE a heavy run') and prescribes the fallback action ('if vram_free is short, call free_memory and re-check'). It also states prerequisites (running ComfyUI), error condition (server_not_running), and warns about target-host ambiguity, leaving little room for mis-selection.

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

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

With no annotations, the description carries the full burden, and it excels: it discloses that target='all' prompts, that ok:True does not guarantee success, that a restart is needed, that updates are mutually exclusive, and that confirm_update_all is only a fallback. It even explains the return envelope is synthesized. No aspect of side effects, error handling, or concurrency is left ambiguous.

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?

Though lengthy, every sentence earns its place. The structure (Intro → Args → Returns → Gotchas) is logical and front-loaded with the purpose. The use of formatting (backticks, bullets) improves scannability. No filler or redundancy is present.

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

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

For a tool with no output schema and no annotations, the description covers all essentials: parameter semantics, return format, failure modes, restart requirements, concurrency constraints, and how to verify success (re-checking freshness.packs). It even references related tools (server_info, switch_comfyui_version) to aid the agent. Nothing an agent needs to call this safely is missing.

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

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

Schema coverage is 0%, so the description must explain both parameters—and it does comprehensively. For target, it enumerates all three values and their effects; for confirm_update_all, it explains when it is read, when to set True, and its role as a fallback. This adds far more meaning than the bare schema with 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 precise action and scope: 'Update the LOCAL install' and enumerates the three targets (core, custom node packs, comfy-cli). It wraps `comfy update <target>`, making the behavior unmistakable. This clearly differentiates it from siblings like install_node (adds nodes) and switch_comfyui_version (changes versions).

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 details each target's effect and when the prompt occurs, and the gotchas clarify concurrency with switch_comfyui_version. However, it never explicitly says 'use this tool instead of X' or lists alternatives; an agent must infer from context that update is for refreshing existing components. It could be more direct about when not to use it, but the context is sufficient for a capable agent.

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

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

With no annotations provided, the description carries full behavioral burden, and it delivers: it discloses overwrite/deduplication behavior, remote target resolution via COMFYUI_URL/COMFYUI_HOST, the comfy-cli >= 1.14.0 requirement, cancellation partial-batch behavior, and the chat-attachment limitation. This gives the agent a realistic model of side effects and failure modes.

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

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

The description is dense but not bloated; the main purpose is front-loaded, followed by an Args section, remote-context note, and Gotchas. Every sentence contributes operational information an agent cannot infer from schema or annotations, so the length is justified.

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

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

For a two-parameter upload tool with no annotations and no output schema, the description covers invocation requirements, environment targeting, version constraints, edge cases, and failure behavior. The only minor omission is a description of the return value, but that does not impede correct invocation, and the description is otherwise exceptionally 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 must compensate. It does: 'paths' is explained by the absolute-path and filesystem-existence requirements, and 'overwrite' is explicitly described ('True replaces an existing file; False (default) keeps it and stores the upload under a deduplicated name'). Both parameters gain meaning beyond bare schema titles.

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 states a specific verb and resource: 'Upload files from this machine into the target ComfyUI's ``input`` directory.' It also gives concrete purpose context ('Stages source images/masks a workflow references by filename — required for img2img/inpaint'), which clearly distinguishes it from sibling tools like download_model, generate_image, and run_workflow.

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

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

The description clearly explains when this tool is needed ('required for img2img/inpaint') and sets important conditions for use, such as 'Every path must exist on THIS filesystem and be ABSOLUTE.' It does not explicitly name alternative tools or exclusion cases, but the context is strong enough for an agent to decide when to invoke 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 provided, the description carries the full burden, and it delivers: it discloses that an invalid workflow is a normal return, that a missing 'valid' key means 'not cleared', that findings keys are optional, and that raising means no verdict. It also lists known blind spots, which is exactly the kind of behavioral context an agent needs 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 longer than average, but every section earns its place: the return contract, the error semantics, and the gotchas are all decision-relevant. It is front-loaded with the core purpose and return contract before the gotchas. Slightly dense, but not padded.

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 validation tool with no output schema and no annotations, the description is remarkably complete. It explains the return shape, error semantics, and known blind spots, so an agent can call it and interpret the result correctly. Nothing critical is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It names the single parameter implicitly via the wrapped command ('--workflow <path>') and the required 'workflow_path' is clear from the schema. It doesn't describe path format or accepted file types, but with only one parameter and the workflow-path semantics evident from the tool name and description, the gap is minor.

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 ('Pre-flight') and resource ('a workflow against the live local ComfyUI'), and immediately distinguishes it from running the workflow. It names the wrapped CLI command and the checks performed (class_types, input shapes, enums, wiring), so an agent can tell it apart from siblings like run_workflow or vary_workflow.

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

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

The description explicitly frames this as a pre-flight step before running, and the 'Gotchas' section gives concrete conditions for interpreting results (e.g., a pass does not guarantee server acceptance, watch for non_node_key warnings, no allocation estimate). It also clarifies when raising means no verdict came back, which is strong when-to-use and how-to-interpret guidance.

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

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

With no annotations, the description carries the full burden and it delivers: it discloses the zip constraint (equal list lengths), type preservation, the quoting footgun and its mitigation, the pre-check behavior (naming the offending entry), and the output routing (stdout NDJSON vs files). This is comprehensive and leaves little to discover at call time.

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 long but justified by the complexity of the slots parameter. It uses clear structural elements: a bolded 'Structured (preferred)' vs 'String' split, bullet points, and inline code examples. It stays front-loaded with the main purpose, but the extensive detail is necessary to prevent misuse. Slightly dense, but not redundant.

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 a mixed union parameter, quoting dangers, and no output schema, the description covers all required ground: input format constraints, error pre-checks, output behavior, and a reference to a sibling tool (list_workflow_slots) for sourcing addresses. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 0% for the top-level parameters, so the description must explain each. It does so well: slots is thoroughly documented with both forms and examples, out_dir is explicitly described (unset default → stdout), and workflow_path is implied via the wrapped CLI command ('comfy workflow vary <path>'). The only minor gap is that workflow_path isn't explicitly named, but it's inferable from context.

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

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

The description opens with a specific verb and resource: 'Fan a frontend-format workflow out into variants over slot value lists.' It clearly distinguishes this from siblings like run_workflow by framing it as a variant-generation operation, and it further differentiates the two input forms (structured vs string). This is unambiguous and specific.

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 concrete usage mechanics: it wraps a CLI command, tells the user to get addresses from list_workflow_slots, and explains the output behavior. However, it never explicitly contrasts this tool with alternatives like run_workflow or set_workflow_slot, so an agent is left to infer when to pick this over those. The when-not-to-use guidance is absent.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose that the tool is a lightweight wrapper around 'comfy which' and that it returns a bare selection answer, which is useful. However, it does not describe the exact output format, whether it can fail (e.g., if no install is targeted), or any side effects. For a read-only query tool, this is adequate but not rich.

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

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

The description is two sentences, front-loaded with the core purpose, and the second sentence provides a precise usage boundary. Every sentence earns its place; there is no fluff 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 zero-parameter, read-only tool with no output schema, the description is nearly complete. It explains what the tool does and when to use it. The only minor gap is not describing the exact output shape or error behavior, but given the tool's simplicity and the explicit comparison to server_info, an agent has enough context to invoke it correctly.

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

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

The tool has zero parameters, so the schema is trivially complete. The description adds context about what the tool reports (the selected workspace) and how it relates to server_info, which is meaningful for an agent deciding to call it. With no parameters, the baseline is 4, and the description meets that.

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 ('Report') and resource ('which ComfyUI install/workspace comfy-cli currently targets'), and it distinguishes itself from the sibling server_info by explicitly noting that server_info already reports the same selected workspace. This makes the tool's purpose immediately clear and differentiates it from related 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 explicitly tells the agent when to use this tool ('only when the bare selection is all you want') and when not to use it (when server_info would suffice, since it reports the same workspace alongside more details). This is clear, actionable guidance that prevents misuse.

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

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

No annotations are provided, so the description carries the full burden, and it does so thoroughly. It discloses that it is read-only, that nothing is installed or changed, that it wraps a ComfyUI-Manager call, what the return manifest looks like, and what happens when the required backend is absent.

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

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

The description is dense but every sentence earns its place: purpose, wrapper, pipeline position, accepted inputs, return format, and key gotchas are all covered in a well-structured layout. The most important disambiguator (read-only mapping, not install) appears first, and the note about node_dependencies is explicitly isolated.

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

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

Despite having no output schema and negligible parameter schema, the description provides the return manifest shape, identifies which keys feed install_node, flags repo URLs versus registry IDs, and explains the unsupported-backend failure. An agent has everything needed to call this tool correctly and interpret its result.

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

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

The schema has 0% description coverage, but the description compensates by explaining exactly what workflow_path accepts: the same workflow JSON as run_workflow, or a .png with an embedded workflow. The parameter name plus the title further confirm it is a path, making the one required parameter fully usable.

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 action and resource: maps workflow node classes to the node packs providing them. It also marks itself read-only, names the underlying command, and explicitly distinguishes itself from node_dependencies, so an agent can identify what it does.

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

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

Gives an explicit pipeline: validate_workflow -> workflow_deps -> install_node -> restart_comfyui. It also states the alternative it is not (node_dependencies) and the prerequisites/failure mode (requires a ComfyUI-Manager comfy-cli can drive), leaving no ambiguity about when it applies.

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