execute_late_booking_cancellation

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

Annotations already declare destructiveHint, non-idempotent and openWorld, so the safety profile is covered; the description adds genuinely non-redundant behavior: one-shot semantics, mandatory account-holder confirmation via confirmedCreditLoss, reconciliation through fresh reads, and that no refund or balance is verified. The lone gap is that 'No refund or balance is verified' is ambiguous about what the response actually reports.

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?

Every clause carries rules, but it is a dense run-on chain and the operative purpose is buried behind the precondition phrase 'After a fresh standard cancellation reports pending-credit-loss'. Front-loading the action itself before the gating condition would improve scanability.

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 shapes need not be spelled out, and the write-safety story is well covered. What remains unresolved is the core ambiguity of whether this single call both surfaces the credit-loss information and performs the cancellation, plus any mention of gymId, leaving the agent to guess at the call's actual effect.

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 carry the load. It does explain confirmedCreditLoss: true as the confirmation gate and hints that actionReference must be the new late reference (not a stale one), but gymId is never mentioned and the 64-hex reference format is left entirely to the pattern.

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 name plus the opening clause make clear this is a late-cancellation write that only fires after a standard cancellation reports a pending credit loss, which distinguishes it from execute_booking_cancellation and the prepare_* siblings. However, the description never plainly states 'cancels the booking and forfeits credit' — the agent must infer the action from phrases like 'the exact still-booked target' and 'possible credit loss', which blurs whether the call previews or commits.

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?

Preconditions and routing are explicit: only after a fresh standard cancellation reports pending-credit-loss, use only the new late reference, recheck the same reservation, send at most one late request. It also states that both preference switches leave the requirement in force, closing off an obvious shortcut an agent might otherwise try.

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