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 known. The description adds genuinely new behavioral context: the side effect on saved leads (they become unassigned) and the dashboard-parity semantics, plus the confirmation requirement. It does not say the list deletion itself is irreversible, which would have completed the picture.

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 short sentences, the core action first, the consequence second, the safety instruction last. No filler and nothing repeated from annotations or schema.

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 two-parameter destructive tool with no output schema, the description covers action, side effect, and confirmation policy — enough to call it correctly. Irreversibility and what a success response contains are left to annotations/absence, which is acceptable but leaves a small gap.

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 50%: request_id is documented as an idempotency UUID, list_id is documented only by name and uuid format. The description adds nothing about either parameter, but list_id is self-evident, so the gap is minor rather than blocking.

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?

Specific verb+resource ('Delete a list') with a follow-on clause clarifying that saved leads survive as unassigned, which implicitly separates it from delete_saved_leads and delete_status. It never names a sibling explicitly, so routing still requires a small inference.

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?

'Ask the user before deleting' is an explicit pre-condition that tells the agent when this tool may be invoked without a confirmation step being skipped. No alternative tool is named for the case where the user actually wants to remove the leads themselves rather than the list.

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