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

Adds material behavior beyond annotations: a $0.03 USDC charge on Base per successful call paid via x402, and an explicit scope disclaimer ('screening aid, not legal advice or a security audit'). The annotations already flag openWorldHint and non-read-only, and the payment disclosure explains why it is not read-only. It stops short of describing auth flow, caching, or failure/refund behavior for the paid call.

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 the core action and checks, and every sentence carries information (checks, verdicts, cost, disclaimer). Slightly penalized for repeating the trigger phrase ('before paying, trading or onboarding' / 'Use before paying, trading with or onboarding an address') and for one very long opening sentence.

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 does the work of explaining return shape (block/review/pass verdict with reasons) and the categories of findings, plus cost and scope limits. What is missing is any detail on error/payment-failure responses or output field structure beyond the verdict.

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 real meaning: the chain enum values are spelled out (Base, Ethereum, Arbitrum, Optimism) and it discloses that Base yields wallet risk heuristics or contract bytecode/proxy checks while other chains do not, so chain choice changes what the caller gets back.

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 and resource ('vet an address') and enumerates exactly what is checked (OFAC SDN match, account type/activity, USD holdings, Base wallet risk heuristics or contract bytecode/proxy checks) and what is returned (block/review/pass with reasons). This distinguishes it from siblings like sanctions_check, contract-risk, and wallet-audit, which each cover only a subset.

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 clear triggering context ('Use before paying, trading with or onboarding an address') and implicitly positions itself against the partial tools via 'Cheaper than buying the parts.' However, it never names the alternatives (sanctions_check, contract-risk, wallet-audit) or states when NOT to use this tool, so the routing signal is inferential rather than explicit.

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