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

Annotations already declare readOnly, idempotent and non-destructive, but the description adds substantial context beyond them: the $0.008 USDC x402 cost per successful call on Base, that unpaid calls return PaymentRequired, that failed calls are not charged, and the lists_as_of freshness signal. These are exactly the operational traits an agent cannot infer from the schema or annotations.

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 routing, then outcomes, then cost. It is dense and mostly earns its length, though the outcome-threshold sentence and the cost sentence are packed with clauses that could be trimmed without losing meaning.

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?

An output schema exists, so return structure need not be described, yet the description still conveys the decision semantics (PROCEED/REVIEW/FLAG/BLOCK and their score bands) and escalation guidance. Combined with cost and list-freshness behavior, an agent has everything needed to invoke and interpret 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 coverage is 100%, so the baseline is 3, but the description adds the operational rule that setting currency_from is what triggers the Bank of Mauritius corridor rate and that currency_to defaults to MUR. That interpretation goes slightly beyond the schema text, which already mentions the corridor rate for currency_from.

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 states a specific verb (screen), resource (both parties of a cross-border payment) and the exact inputs checked: names against watchlists, country AML risk, and the optional corridor rate. It is immediately distinguishable from screen_wallet (wallet addresses) and create_travel_rule_packet (Travel Rule record), which are named explicitly.

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 the positive case ("use it for fiat or crypto payments where you have names") and two named alternatives with the conditions that select them (screen_wallet for wallet addresses only; create_travel_rule_packet for a stored, verifiable record). This leaves nothing to inference.

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