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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context: direct cancellation only applies to an exact unfiled version, and otherwise it requests a safe Filing Operations review after confirmation. This conditional behavior goes beyond what annotations alone communicate, with no contradictions.

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 sentence that leads with the verb 'Cancel' and conveys the core behavior plus a conditional alternative without wasted words. It is compact and front-loaded, though slightly dense and potentially ambiguous in its phrasing.

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 has six parameters, is destructive, and has two behavioral branches, the description is relatively thin. It does not clarify when the review path is triggered, what 'safe Filing Operations review' entails, or what role reason and idempotency_key play. The output schema exists, so return values need not be explained, but the conditional logic and prerequisite conditions could be spelled out more clearly.

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 compensate for parameter meaning. It only alludes to expected_version ('exact version') and confirmation_token ('after confirmation'). It leaves reason, idempotency_key, project_id, and case_id unexplained, even though some are self-explanatory by name. The description provides minimal parameter-level guidance for a tool with five required parameters.

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 (cancel) on a specific resource (unfiled incorporation version) and distinguishes between direct cancellation and requesting a Filing Operations review. It is clearly distinct from sibling tools like incorporation.start_case or incorporation.update_draft, though the two-mode phrasing could confuse an agent about the primary purpose.

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 this tool: to cancel an unfiled incorporation version. It also hints that a review request path exists after confirmation. However, it does not explicitly contrast it with alternatives or state when the review path should be chosen over direct cancellation, leaving the selection logic to be inferred.

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