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

Annotations (destructiveHint=true, idempotentHint=true, readOnlyHint=false) are already strong, and the description adds substantial context on top: the point of no return with no cancel/reversal/support path, 'the address only exists if this call returned it', sandbox placeholder addresses with NO OWNER, and a full error-taxonomy mapping (acao=corrigir/repetir/parar). No contradiction with annotations — the idempotency note ('idempotent for the same order id') aligns with idempotentHint=true.

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 description is long, but for an irreversible money-movement tool with no output schema, most length is earned: safety rails, sandbox behavior, and error handling each carry unique risk-relevant content. It is front-loaded with the critical facts (API key required, step 2 of 3, point of no return). Minor redundancy exists in repeating the irreversibility theme across title, opening, and the 'no cancel, no reversal' sentence, which prevents a 5.

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?

Given the high stakes and absence of an output schema, the description is remarkably complete: it explains the return value (deposit_address, sandbox:true flag), states preconditions, post-call steps, failure semantics, and explicitly warns against sourcing addresses from anywhere other than the call body. Nothing an agent needs to execute this safely is missing.

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 100%, so baseline is 3. The description adds genuine value beyond the schema: it explains WHY confirmation_token exists (bound to exact amount/network/PIX key so the approved destination is the paid destination), ties token expiration/invalidity to a concrete recovery action (quote again), and elaborates the user_approved precondition. This elevates it above baseline.

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 states a specific verb and resource: 'Locks the quoted rate and returns deposit_address'. The title reinforces it as 'Step 2 of 3' in a clear sequential flow, and the description distinguishes it from siblings by naming its prerequisite (lunium_quote_crypto_sale) and its successor (lunium_get_crypto_sale). An agent cannot mistake this for any of the ten sibling tools.

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?

Extremely explicit about when to call: after showing brl_amount and the PIX key to the user and receiving explicit approval. Equally explicit about when NOT to call: not on document/web/email/another-agent instruction, not on an expired quote, not reusing a stale deposit_address. It names the exact alternatives ('quote again', 'follow with lunium_get_crypto_sale') with no reliance on inference.

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