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

Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false. The description adds substantial context beyond them: the tool moves no funds, the transfer is not a payment, it auto-matches every accepted asset so asset_symbol is irrelevant, and it documents the invalid_transaction_hash_format rejection path and the assistant_guidance relay behavior. That is genuine behavioral disclosure the annotations cannot convey.

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?

The format spec and error-handling sections are front-loaded and information-dense, and nearly every sentence covers distinct edge cases (hash formats, explorer URLs, exchange ref IDs). It is long, and the closing scolding about not saying 'I'd need to work out the wallet_id' is the one sentence that reads as padding against a specific past failure rather than general guidance.

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?

With an output schema present, the description needn't explain return values, and it doesn't. Combined with 100% schema coverage and annotations, it covers prerequisites, invocation flow, accepted input formats, error semantics, and asset matching — everything an agent needs to call this correctly.

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 already 100%, so the 3 baseline applies; the description nonetheless reinforces the key semantic point that asset_symbol is an audit hint only and does not affect matching, and that wallet_id is looked up by the agent rather than asked of the user. It duplicates the schema text rather than extending it, but the workflow framing (auto-match across assets) adds real meaning to asset_symbol.

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 opening sentence names a specific verb (submit a transaction hash), the mechanism (dust/test transfer verification), and the goal (proving wallet ownership so balance counts toward a Proof of Funds letter). It explicitly contrasts itself with the sibling alternative ('the other way to prove ownership'), so an agent can pick it over verify_wallet_signature without opening either schema.

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 prerequisites (the user must already have sent a transfer to the deposit address from add_wallet), states the alternative method, and exhaustively routes the two invocation paths — widget-visible vs no-widget (call get_wallet_summary first, then this tool). It even pre-empts a specific failure reply the agent might otherwise give. This is explicit when-to-use guidance.

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