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

Annotations only declare readOnlyHint and openWorldHint; the description goes substantially beyond them by disclosing the paid x402 model and exact cost ($0.002 USDC per call), the multi-chain data provenance, and ranking/copycat-warning behavior. That pricing disclosure is genuinely decision-relevant for an agent wallet. It stops short of describing response shape or failure behavior.

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?

One dense sentence plus a cost clause, front-loaded with the purpose and then layering sources, ranking behavior, and price. Nearly every clause earns its place; the chain enumeration is slightly list-heavy but serves the chain parameter.

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 carries the return-behavior burden and does so partially ('ranked so the genuine token comes first; warns about copycats'). The paid-call disclosure and chain coverage make it callable without ambiguity, though the undocumented 'limit' parameter and the absence of any response structure leave a small gap.

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 only 33%: only 'chain' is documented. The description partly compensates by enumerating covered chains (which maps to the chain values) and clarifying that q is a name or symbol. But 'limit' is undocumented in both schema and description, so the coverage gap is not fully closed.

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 ('Find a token's real contract address by name or symbol') and immediately qualifies the scope with the data sources used (curated Uniswap list across seven EVM chains plus Jupiter for Solana). An agent can distinguish this lookup tool from siblings like token_price, token_chart, or token_holders without opening a 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?

The trigger is implied clearly enough ('find a token's real contract address'), and the copycat warning hints at the disambiguation use case. However, no alternatives are named among the dense set of token siblings (token_scan, token_verdict, address_verify, token_report), and no when-not condition is given, leaving routing to inference.

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