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

Annotations cover safety (readOnly, non-destructive, openWorld), and the description adds real value beyond them: cost model ($0.01/call, first 25 free, failed calls free) and the explicit note that each call is charged so repeats are not free — which meaningfully explains the idempotentHint=false. It also discloses output shape (block/review/pass with reasons) and a legal disclaimer, though no rate limits or latency expectations.

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 opening sentence is one long semicolon-chained clause that is dense to parse, and the instruction "Use before paying, trading with or onboarding an address" nearly duplicates the opening "Screen a payee before paying, trading or onboarding." Pricing and disclaimer content is useful, but the block is longer than it needs to be.

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 no output schema, the description still tells the agent the return is a block/review/pass verdict with reasons, plus cost and per-call charging. Missing only scoring detail or how to interpret a partial (e.g., domain-only) result, which is a minor gap for a 3-parameter read-only tool.

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 100%, so all three parameters (address, chain enum, optional domain) are already documented. The description restates the chain list and the domain's effect (domain age and trust flags) plus an example address, but adds no syntax or format detail the schema lacks. Baseline 3 applies.

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?

States a specific verb (screen/vet) and resource (payee EVM address) plus scope: OFAC SDN match, account type, holdings, Base risk checks, optional domain signals. Clear enough to be actionable, but it never distinguishes itself by name from close siblings like check_payee or sanctions_check, which an agent selecting among 25 tools would need.

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?

"Use before paying, trading with or onboarding an address" gives a clear situational trigger. There are no explicit exclusions or named alternatives (e.g., when to prefer sanctions_check or check_x402_seller), so routing among overlapping siblings is still left to inference.

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