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

With no annotations provided, the description carries the full burden. It discloses that the tool operates in parallel, Claude synthesizes outputs, verifies against the repository, and produces a final conclusion. However, it does not mention side effects, cost, rate limits, or data privacy risks of sending questions to external models—important for a tool that makes external calls.

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 three sentences, front-loaded with the core action, and every sentence contributes meaning. It is concise without sacrificing essential 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?

Given the tool's complexity (external calls, comparison, synthesis) and the absence of annotations, the description provides the core workflow but lacks operational context such as error handling, latency, cost, or permission implications. An output schema exists, so return values need not be described, but the description is still somewhat thin for a tool with side effects.

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 only 33%, and the description adds minimal parameter-level detail. It implies 'task' is the shared question and 'providers' maps to 'two or three external models', but it does not clarify the meaning of 'mode', 'reasoning_effort', or 'max_output_tokens'. The description does not compensate for the low schema coverage.

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 asks two or three external models the same question in parallel, which is a specific verb+resource+scope. It also describes the follow-up actions (compare, verify, synthesize), making it distinct from sibling delegation tools that likely send to a single model.

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 an explicit 'Use when' condition: 'independent opinions materially improve confidence.' It implies this tool is for high-stakes or ambiguous tasks, but does not explicitly name alternatives or exclusions. This is clear 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 of behavioral disclosure. It transparently states that the external model cannot inspect files beyond the supplied context and cannot modify the workspace, which are critical safety and scope constraints. It could mention data privacy or network dependencies, but the key behavioral traits are effectively conveyed.

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 three sentences long, front-loaded with the primary action, followed by use cases and limitations. Every sentence adds unique value, and there is no redundant or filler content.

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 moderate complexity (external model call, 5 parameters) and the presence of an output schema, the description provides adequate context: purpose, use cases, and key limitations. It does not explain potential async behavior, cost implications, or failure modes, but those are not essential for basic selection and invocation, especially with the output schema present.

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 only 40%, so the description should compensate for undocumented parameters. The description clarifies the purpose of the context parameter ('cannot inspect files beyond the supplied context') and implicitly explains the provider parameter by naming Codex, Grok, and DeepSeek. However, it does not elaborate on reasoning_effort or max_output_tokens, which remain vague without additional schema descriptions.

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 with a specific verb and resource: 'Ask Codex, Grok, or local DeepSeek for independent analysis.' It also lists concrete use cases (debugging hypotheses, architecture evaluation, repository reasoning, second opinion) that distinguish it from siblings like delegate_review and delegate_patch.

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 to use the tool ('Use for debugging hypotheses, architecture evaluation, repository reasoning, or a second opinion') and provides clear context for its applicability. It does not name alternative tools or include explicit when-not-to-use conditions, but the use-case list is sufficiently specific to guide an 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 the full burden of disclosure. It meaningfully warns that the tool only proposes a patch and does not apply it, and it outlines Claude's responsibility to inspect, validate, apply, format, test, and review. This is a critical behavioral trait that goes beyond the tool's name. It doesn't cover costs or rate limits, but the main surprise factor is addressed.

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 long. The first sentence conveys the core purpose, and the second delivers the essential caveat about not applying changes. Every word is meaningful; there is no filler 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?

The tool is well-scoped with an output schema, and the description clearly explains what the tool does and what it does not do. The missing guidance on provider selection and optional parameters is a minor gap, but the core context needed for a delegation tool is present. Overall, it is fairly complete for an agent to assess whether to invoke it.

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

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

The schema description coverage is only 40% (task and context have descriptions), yet the tool description adds no parameter-level guidance. It doesn't explain what 'provider' options mean, what 'reasoning_effort' controls, or how 'max_output_tokens' should be set. With low schema coverage, the description was expected to compensate but did not.

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 ('Ask an external model') and a specific deliverable ('a minimal unified diff'), and explicitly notes that the tool does not apply changes. This clearly distinguishes it from the sibling tools delegate_analysis and delegate_review, which likely focus on analysis and review rather than patch generation.

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 to use this tool: when an external perspective on a minimal diff is needed. It also states a key exclusion ('does not apply changes') and the follow-up steps Claude must take. However, it does not explicitly name alternatives like 'delegate_analysis' for analytic tasks, so it lacks explicit when-to-use-other-tools 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 transparency burden. It discloses 'read-only' behavior, which is a key safety trait, and prescribes a verification workflow ('Claude must verify each material finding'). It does not detail external model quirks or error behaviors, but for a read-only review tool this is sufficient.

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

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

Two concise sentences with front-loaded purpose and clearly scoped usage examples. Every sentence earns its place 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?

The tool has moderate complexity (5 parameters, output schema) and the description covers the primary use cases and safety constraints. It does not explain the difference from delegate_analysis, but the output schema and clear purpose make it complete 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 only 40% (only task and diff_or_context are described). The description adds no parameter-level guidance, leaving reasoning_effort and max_output_tokens to be inferred from names/enums. The description does not compensate for the low coverage.

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

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

The description states a specific verb and resource: 'Request a read-only code review from one external model.' It clearly distinguishes from sibling tools like delegate_patch and delegate_analysis by specifying 'read-only code review' and 'one external model.'

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 explicit use cases: 'correctness, regression, security, concurrency, data-loss, or missing-test review.' It also instructs that Claude must verify each material finding, but it does not mention when not to use the tool or name alternatives, 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It explicitly states that the tool performs no model inference, signaling a lightweight, read-only operation. It does not detail output structure or potential error behaviors, but these are less critical given the tool has no parameters.

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 concise sentences. The first sentence states the primary purpose, and the second adds a meaningful constraint ('no model inference') without unnecessary 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 zero parameters and the presence of an output schema, the description is sufficient to understand the tool's scope and behavior. It correctly sets expectations for connectivity and availability checks without promising inference or model interactions.

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 baseline is 4 per the rubric. The description provides no parameter information because none is needed; there is nothing to clarify 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 uses a specific verb ('Verify') and names the exact resources (CLIProxyAPI connectivity and companion model availability). It clearly distinguishes its purpose from siblings like list_companion_models, which would list models rather than check their health.

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

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

The description implies when to use the tool: when you need to verify connectivity to CLIProxyAPI and availability of companion models. It does not explicitly exclude alternatives or state 'when not to use', but the unique purpose is clear enough to guide 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 burden of transparency. It discloses the main behavior: listing IDs and reporting availability status. It is a read-only operation; the description's wording implies no side effects, which is adequate for a simple listing tool.

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

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

The description is a single, tightly written sentence that leads with the action and resource. Every word contributes meaning, with no wasted text.

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

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

The description fully explains the tool's purpose for a zero-parameter list operation. Since an output schema exists, it does not need to detail return values. The mention of specific configured models adds necessary context.

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 (empty object). Per the rules, the baseline for 0 params is 4, and the description correctly does not add unnecessary param information.

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

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

The description uses a specific verb ('list') with a clear resource ('model IDs exposed by CLIProxyAPI') and adds the availability check for specific configured models. This clearly distinguishes it from sibling tools like delegate_* and compare_models.

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 conveys clear usage context by stating it lists model IDs and checks availability of Codex, Grok, and DeepSeek models. It does not explicitly mention alternatives or when not to use it, but for a zero-parameter listing tool the context is sufficient.

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