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

Beyond the annotations (destructiveHint, idempotentHint), the description reveals that both reservation_id and pin are required as proof of booking ownership, that cancellation is impossible without the pin, and that the pin must never be invented or guessed. This substantially clarifies the safety-critical behavior for an agent.

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 sentences, front-loaded with the core action, followed immediately by the critical prerequisite and a clear 'must ask' instruction. No filler or redundant material.

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 action with three required parameters and no return-value obligations, the description covers the action, all invocation prerequisites, and the fallback behavior when the pin is missing. The parameter details in the schema fill any remaining gaps.

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?

The schema already documents all three parameters (100% coverage), but the description adds the relationship between reservation_id/pin and the original booboooking_book call, plus the hard constraint that the pin must come from conversation state, not be fabricated. This goes beyond the schema's per-parameter text.

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 the exact operation ('Cancel a reservation on booboooking.com') and clearly differentiates from siblings such as booboooking_book and booboooking_get_booking. It also specifies the ownership proof requirement tied to the original booking call.

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?

Gives an explicit trigger ('If the user asks to cancel...') and a concrete procedure for the missing-pin case. It does not explicitly discuss alternatives, but sibling operations are sufficiently distinct that no exclusion is necessary.

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