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

Annotations already declare destructiveHint=true and idempotentHint=true, so 'safe to call more than once' largely restates structured data. The one real addition is the word 'Request,' implying cancellation may be queued rather than immediate. However, for a destructive operation the description never says what is destroyed or what state the investigation is left in, which is the main behavioral gap.

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, action first and the safety caveat second. Nothing is padded and nothing repeats the title verbatim beyond what is needed to state scope.

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, and annotations cover the safety profile. What remains missing is what happens after the request (does cancellation take effect immediately, can it be reverted, what happens to in-flight findings), which matters for a destructive operation.

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 50%: idempotency_key is well documented in the schema, but investigation_id has no description anywhere. The tool description mentions neither parameter, so it does not compensate for the undocumented half, leaving the format and source of investigation_id entirely implicit.

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 resource: 'Request cancellation of a running investigation.' The verb 'request' signals this may be asynchronous rather than an immediate cancel, which is a meaningful distinction. No sibling in the list performs cancellation, so no explicit differentiation is needed, but the description never clarifies what a 'running' investigation is versus other states.

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 only guidance offered is 'Safe to call more than once,' which is an idempotency trait, not a when-to-use rule. There is no mention of prerequisites (must the caller own the investigation?), when cancellation is appropriate versus letting an investigation finish, or what to do if it already completed.

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