comfy_list_partner_apis

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds genuine value by explaining the internal intersection mechanism (installed extensions ∩ curated catalog) and clearly documenting the return structure (installed vs. available), which goes beyond the safe-read declaration.

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?

Excellent structure: a focused first sentence stating what the tool does, a second sentence explaining the underlying mechanism and use case, and a clean Returns section documenting the output shape. Every sentence contributes distinct value with no fluff. Marginal deduction only because the vendor list example could be considered slightly illustrative rather than essential.

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?

Complete for this tool's complexity. The catalog-intersection logic is fully explained, the return values (installed and available) are documented, and the output schema reinforces the return contract. With zero parameters, no prerequisites, and a documented output structure, the agent has everything it needs to invoke this 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?

The tool takes 0 parameters, and the rubric establishes a baseline of 4 for this case. The description doesn't waste space on parameters but instead documents the output format, which is the only semantic surface area that exists. The Returns section functionally serves the 100% coverage role that parameter docs would for parameterized tools.

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

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

Specific verb+resource+scope: "List partner-API custom nodes installed on the connected ComfyUI" clearly identifies what is listed (partner-API custom nodes) and the context (installed on the connected ComfyUI). The description also distinguishes this from the sibling comfy_list_extensions by explaining it filters through ComfyPilot's curated KNOWN_PARTNER_APIS catalog.

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 clear context for when to use: "Useful before suggesting workflows that depend on cloud-backed nodes - tells the agent which vendors (Veo, Kling, Seedream, GPT-Image, etc.) are actually wired up on this server." This gives actionable decision-making context. However, it doesn't explicitly name any alternative tool or exclusion cases, so it stops short of full when/when-not guidance.

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