Delete estimate deposit

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

The annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is fully covered by structured data. The description adds almost nothing beyond that: it does not say whether the deposit's associated transaction is also removed, whether the estimate balance is recalculated, or whether the deletion is reversible.

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?

A single short sentence that is front-loaded with the action and has no filler or redundancy. It is efficient but borders on under-specification rather than tight communication.

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 mutation with no output schema, the description should explain the consequences of deletion and the relationship to the parent estimate and underlying transaction. It says only that the payment is deleted, leaving the agent to guess at side effects before performing an irreversible operation.

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?

With a single parameter at 100% schema description coverage ('Estimate payment ID'), the schema already carries the meaning, so the baseline of 3 applies. The description contributes no additional detail about ID format, source, or whether an estimate-scoped ID is accepted.

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 ('Delete a recorded estimate deposit payment'), which is far clearer than a tautology. However, it does not distinguish this tool from close siblings such as wave_delete_estimate (removes the whole estimate) or wave_update_estimate_deposit / wave_record_estimate_deposit, so an agent must infer the boundary from names alone.

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 when-to-use or when-not-to-use guidance, no prerequisite that the payment must already be retrieved via wave_get_estimate_payment, and no pointer to the alternative of updating rather than deleting. The only implied guidance is the word 'recorded', which hints at a precondition but never states it.

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