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

With no annotations, the description carries the full burden and does real work: it discloses that all nodes and shards are destroyed, that billing ends as a side effect, that already-scored partial results survive, and that the call remains reachable even if the agent goes silent. It stops short of stating irreversibility or permission requirements.

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

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

Three short, front-loaded sentences with no filler; the outcome ('Ends billing') is stated immediately after the action. The final clause about the agent going silent is slightly cryptic but still carries 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?

An output schema exists, so return values need not be explained. For a destructive kill operation with zero annotations, the description covers consequences well but omits irreversibility, preconditions on plan_id, and error behavior — meaningful gaps for a termination tool.

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 is one required parameter at 0% schema description coverage, and the description only implies that 'a plan' has an identifier — it never explains what plan_id is, its expected format, or whether it must reference an active plan.

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 scope: stop every node and shard belonging to a plan, plus the visible outcome (billing ends). It is clearly distinct from plan/launch/status/results siblings by virtue of being the termination action, though it never names them.

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

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

Usage is implied by 'Stop every node and shard belonging to a plan' and the note that partial results are preserved (so an agent need not wait for scoring to finish before calling). However, no explicit when/when-not conditions or alternatives among the sibling tools are given.

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 does real work: it discloses pre-dispatch balance and cost-ceiling re-checks, progress streaming via ctx.report_progress, and logging via ctx.info. However it omits key behavioral facts for an unannotated execution tool — whether the call is asynchronous/long-running, what happens if the ceiling check fails, what occurs on an already-running job, and whether it is safe to retry.

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?

Three short, front-loaded sentences with no filler; the core action comes first and the pre-flight checks and progress reporting follow. Slight loss because the terse jargon ("enumerated space", "ctx.report_progress") reduces clarity per word.

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?

Output schema exists, so return values need not be explained, and parameters are fully covered by the schema. Still missing for a job-launching tool: the lifecycle relationship to plan/status/kill, the async nature, and failure behavior when the cost ceiling check rejects dispatch.

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 100% and all three parameters are documented in the schema, including that plan_id comes from brute_genius_plan and that chip/nodes override plan-time choices. The description adds no further parameter meaning, so the baseline 3 applies.

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 verb phrase "Shard the enumerated space and score every combination" identifies the operation, but the terminology is domain jargon and never states plainly that this launches an execution job from a plan. Nothing distinguishes it from brute_genius_plan or brute_genius_status, so the agent must infer that this is the 'run it now' step.

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

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

There is no when-to-use guidance, no precondition beyond the schema's plan_id, and no mention of the alternative/sibling actions (poll brute_genius_status, abort with brute_genius_kill, fetch with brute_genius_results). The agent gets no signal about when launching is appropriate versus checking an existing run.

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 load and does disclose two meaningful behaviors: it is a pure read/compute operation with no execution side effects, and it hard-refuses (returns no plan_id) when estimated cost exceeds max_cost_usd. It does not say whether a refused call still costs anything, whether plans persist or expire, or what a successful plan_id is used for downstream.

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 short sentences, the core action front-loaded, then the two constraints. Nothing is padded and no sentence restates the tool name.

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

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

An output schema exists to describe the plan and cost estimate, so the description need not explain return values. For a 5-parameter, fully documented, non-destructive compute tool, the description covers the two facts an agent cannot infer: no execution and cost-ceiling refusal.

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 100% and every parameter is documented in the schema, including max_cost_usd as a 'hard ceiling'. The description's only added parameter meaning is the refusal consequence of max_cost_usd, which the schema already states, so the baseline 3 applies.

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 concrete verb and resource (enumerate the Cartesian product of the `space` mapping, return a cost estimate) and immediately rules out the biggest ambiguity by saying 'Does NOT execute anything', which separates it from brute_genius_launch. An agent can tell what this does and what it does not do without opening the 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 non-execution clause and the refusal rule give a clear context for when this tool is the right call (sizing a sweep before committing) and implicitly route execution to brute_genius_launch. However, no sibling is named explicitly and there is no statement about when planning is unnecessary or what to do when the plan is refused.

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 must carry the full behavioral burden. It discloses descending order and top_k truncation, but says nothing about whether the call blocks, what happens if the plan is incomplete, error conditions, or read-only safety.

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

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

A single front-loaded sentence that states the return set and ordering rule without filler. It is efficient, though its brevity leaves gaps elsewhere.

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

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

An output schema exists, so return values need not be explained. Still, for a required plan_id tool with no annotations, the description omits the plan lifecycle context and preconditions needed 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 description coverage is 0%, so the description must explain both parameters. It clarifies that top_k controls how many highest-scoring combinations are returned, but never explains plan_id, which is required and is the key input for selecting a plan.

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?

It states a concrete retrieval action (return top_k highest-scoring combinations) with an ordering rule. However, 'combinations' and 'results' are not tied to the brute_genius_plan/launch lifecycle, so it is not clearly distinguished from brute_genius_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?

There is no guidance on when to call this rather than brute_genius_status, nor whether the plan must be launched or completed first. The plan_id prerequisite is implied only by the parameter name.

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. 'Return' implies a non-mutating read and the metric names hint at the payload, but it says nothing about behavior when plan_id is unknown, when the plan is finished/killed, or about polling cost — gaps for a no-annotation 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?

One front-loaded sentence with no filler; the key metrics are listed compactly. It reads as a fragment rather than a full sentence, but nothing is wasted.

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

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

An output schema exists, so the return shape need not be explained, and the description correctly focuses on what the status conveys. Remaining gaps (plan_id provenance, behavior on completed plans) are minor given the output schema.

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% and the single parameter plan_id has no description in either place; the tool gives no hint that plan_id comes from brute_genius_plan. Only one parameter exists, so the gap is limited, but the description adds no meaning beyond the 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?

States a specific verb ('Return') and resource ('live progress') plus the concrete metrics returned (shards done, combinations evaluated, best-so-far). It is clearly distinct from brute_genius_results, plan, launch and kill by being a status read, though it never explicitly names those siblings to reinforce the contrast.

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?

'Live progress' implies this is what you poll while a run is active, which differentiates it informally from the results tool, but no explicit when/when-not or alternative (e.g. 'use brute_genius_results once the run is complete') is given.

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 must carry the behavioral load; 'detect and report' reasonably implies a non-destructive read and 'machine/fleet' scopes the search surface. It doesn't address cost/latency of fleet scanning, hardware/permission prerequisites, or whether results are cached.

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

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

A single front-loaded sentence with zero filler. Appropriately sized for a simple probe, though it leans terse enough that it omits guidance the dimension doesn't penalize as verbosity.

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

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

An output schema exists so return values needn't be described, and the single parameter is fully documented in schema. Still, for a tool that may enumerate a whole fleet, the absence of any cost, permission, or timing context leaves an agent 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?

Schema coverage is 100% and the schema itself explains that 'chip' is informational only and detection is exhaustive. The description adds nothing about the parameter, so the baseline 3 applies.

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 pair ('detect and report') and resource ('available accelerators') with a scope qualifier ('current machine/fleet'). It's unmistakable against the brute_genius_* siblings, which occupy a different domain, though no explicit differentiation is offered.

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?

No indication of when to call this versus alternatives, whether it should be run before launching work, or whether it is expensive on a fleet-wide scan. The usage is only inferable from the stated purpose.

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