comfy_recommend_runtime

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

Annotations declare readOnlyHint=true and idempotentHint=true, and the description aligns with this by not indicating any side effects. The description adds value beyond annotations by explaining the specific verdict logic and the additional output of the install flag. It does not contradict annotations, but it doesn't detail how the inspection is performed or whether it accesses system APIs, which is minor given the safety profile.

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 overview, a list of verdicts with thresholds, and a note on the additional output. It is front-loaded with the primary purpose and each sentence contributes to understanding the tool. No fluff or redundancy.

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

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

Given there are no parameters and an output schema is present, the description is complete for the tool's complexity. It fully explains the verdicts and the install flag, so the agent can confidently use the result to route workloads. No gaps in critical information.

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 no parameters, so the baseline is 4. The description explains the output semantics extensively, including the three verdicts and the install flag, which goes beyond what an empty schema provides. This is useful for understanding the tool's return value.

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

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

The description clearly states the tool's purpose: inspect connected GPU and recommend local vs Comfy Cloud routing. It distinguishes itself from siblings like comfy_check_vram and comfy_get_gpu_info by focusing on the routing decision. The three verdicts provide specific, actionable output.

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

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

The description explains when to use this tool: before deciding to run workloads locally or on cloud. It also gives concrete thresholds for each verdict, making it clear how to interpret the result. However, it does not explicitly state when NOT to use it versus alternatives like comfy_check_vram, but the purpose differentiation is implicit.

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