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

Annotations only flag a non-read-only, non-destructive, non-idempotent open-world call; the description goes well beyond that by explaining that the call merely produces an invoice, that payment occurs only if someone sends USDT, the exact expected amount range (29.01–29.99 USDT), the default chain, and that the bearer token is optional. This is precisely the behavioral context an agent needs before touching money.

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?

Front-loaded with purpose and product terms, then the three call shapes in order of likely use; nearly every clause carries decision-relevant information. It is dense and the price/amount sentence is long, but no sentence is filler.

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 multi-mode, payment-adjacent tool with no output schema, the description covers all three call shapes, cost, deliverables, chain choice, and the safety gate. Nothing needed to invoke any mode correctly 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 the field-level meanings are already documented; the description nevertheless adds the pairing semantics that invoice_id and adoption_token are used together for a payment check, and restates the sign_name constraints and network default in the flow context. Marginal but real value on top of the schema.

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 concrete verb and resource ("Adopt an olive tree on Hamid's family farm near Marrakech") and immediately qualifies the product category ("A gift product, not an investment; no oil is shipped"). It also enumerates exactly what the adoption delivers, so an agent can distinguish it from any sibling without opening the 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?

It gives three explicit invocation modes and the condition selecting each: {"sign_name": ...} to create an invoice, {"invoice_id", "adoption_token"} to check payment, and {} for the offer. It adds a genuine exclusion — nothing is charged by this call — plus an explicit instruction to obtain human approval before paying.

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