Request queue cancellation

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

The description adds real behavioral context beyond the annotations: the receipt is explicitly not proof that processing stopped or credits were refunded, eligibility depends on current provider state, and retries should not be attempted. This meaningfully supplements destructiveHint=true and idempotentHint=false, though it omits any note on permissions/auth or what happens to already-consumed work.

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 tight sentences, front-loaded with the action and immediately followed by the two caveats that matter most. Nothing is redundant, though the clipped phrasing borders on cryptic and could be slightly more explicit without adding length.

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 destructive, non-idempotent mutation with no output schema, the description supplies the key caveats an agent needs: it may not stop processing, refunds are not guaranteed, and retrying is discouraged. It does not mention the required confirm/account inputs or any failure modes, but the schema covers those.

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%, so the schema already documents model_id, request_id, account and confirm in detail. The description's 'Confirmed' wording loosely echoes the confirm flag but adds no syntax, format, or dependency meaning beyond the schema, making the baseline 3 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 phrase 'Confirmed native cancellation request' conveys that this cancels something, and the title 'Request queue cancellation' pins the resource to a queued request/job. However, the description never states a clean verb+resource ('cancels a submitted job') and gives no differentiation from siblings like delete_request_payloads or get_job_status, so the agent must infer the object of cancellation.

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 retry' and 'current provider state controls eligibility' imply when this call is appropriate and when repeating it is pointless, which is useful. But there is no explicit when-to-use vs alternatives guidance (e.g., cancel vs delete payloads vs just polling status), so the agent gets only fragments of routing logic.

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