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

Annotations already mark the tool as destructive, and the description adds useful behavioral nuance: it voids a pending match from this request, keeps matches both people accepted, and leaves other requests active. This goes beyond the annotation's simple destructive flag, though it does not detail irreversibility or permissions. Still, the added context is valuable.

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 five short sentences with no filler. The main action is front-loaded, the critical parameter instruction comes second, and each subsequent sentence adds a distinct useful detail. It is concise while still covering disambiguation and behavioral effects.

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 single-parameter tool with no output schema, the description covers what the tool does, when to use it, how to resolve ambiguity, and what effects it has on pending and accepted matches. The annotation covers the destructive nature. Nothing essential is missing 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 coverage is 100%, so the parameter is already documented. The description adds practical guidance by emphasizing 'Always pass its request_id' and explaining which request_id to use. It also routes ambiguity to check_matches, which helps the agent provide the correct value.

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 and resource: 'Withdraw one match request, either a draft or an open one.' It clearly states the scope and distinguishes the action from the sibling tools such as check_matches and confirm_match_request. An agent can understand exactly what operation this tool performs.

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 explicit guidance: always pass request_id, and 'If it is unclear which one the user means, call check_matches first.' It also clarifies behavioral boundaries: other requests stay active and accepted matches are kept. This gives the agent clear selection and disambiguation rules relative to alternatives.

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