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

Annotations already cover safety (readOnly, non-destructive, open-world), so the description adds real value by disclosing the paid cost (0.010 USDC), the supported chains, the real-time nature, and the pre-trade honeypot verification. What it does not disclose is how payment is settled or whether a wallet/auth is required before the call succeeds.

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?

Two compact sentences: capability first, commercial/latency constraint second. Zero filler and nothing important buried at the end.

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 one-parameter read tool with an output schema, this is nearly complete: chains, cohort, freshness, safety check, and price are all stated. The remaining gap is operational context around the paid endpoint (how the 0.010 USDC is charged, whether repeated calls are billed, any latency or rate limits), which matters when an agent decides whether to invoke it.

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?

With a single parameter at 100% schema coverage, the schema already explains the accepted formats (Base 0x contract or Solana SPL mint). The description adds only the chain framing ('on Solana and Base'), which the schema effectively already conveys, so it neither compensates for nor extends parameter meaning.

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+resource ('Returns real-time DEX trades') with clear scope: only trades by labeled smart-money/whale wallets, only on Solana and Base. It implicitly differentiates from siblings like rugshield_smart_money_netflow (aggregate flows) and rugshield_tgm_who_bought_sold (holder-level trades), but never names them, so the distinction is inferential rather than explicit.

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?

Usage is implied: this is the tool for watching what labeled smart wallets are actively buying/selling in a token. There is no explicit when-to-use or when-not-to-use guidance, and no routing to the closely related siblings (netflow, who_bought_sold, pre_swap_scan) that an agent would need to choose correctly.

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