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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds two things the annotations don't: the messages of the acked leases are permanently deleted, and a lease that expired and was reclaimed is reported in a 'lost' field rather than silently acked. That 'lost' nuance is genuinely useful safety context 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?

Two short sentences with no padding, and the destructive outcome is front-loaded. The 'Done:' opener is slightly cryptic as a leading token but does signal the completion semantics efficiently.

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, idempotent operation the safety profile is covered by annotations and the schema is fully described, but the description still omits the ack-vs-nack decision and any notion of how partial or failed acks are reported. The 'lost' note helps but does not close those 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?

Schema description coverage is 100%, so every parameter (queue, leases, instance_id, passport_token) is already documented, and 'these leases' refers to the leases array. The description adds no format, limit, or cross-reference detail beyond the schema, so baseline 3 applies.

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 conveys the effect ('the messages of these leases are deleted') and the opening 'Done:' hints at successful completion, but it never states the action verb (acknowledge) or the resource in its own words — that lives only in the title. It gives no signal distinguishing this from the closely related queue_nack sibling.

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?

There is no explicit guidance on when to call this versus alternatives; the natural pairing with queue_nack (return messages for retry) is never mentioned. 'Done:' only weakly implies the job-completed case, leaving the agent to infer the decision rule.

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