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

With no annotations provided, the description carries the full behavioral disclosure burden. It discloses the cost ($0.01 via x402), live data source (Blockscout), output field details, and wallet categorization flags (contract? named? scam-flagged?). This is substantial context beyond a simple read; the only omission is explicit statement of read-only/non-destructive behavior and potential rate limits, but the feed nature makes that largely implicit.

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 description is moderately sized but packed with high-value information: cost, purpose, output fields, use case, related tools, and source. It front-loads the core value and payment, and every sentence contributes. The marketing-style phrases ('Nansen-style whale alert without the subscription') add color but do not pad unnecessarily.

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 tool with no output schema and no annotations, the description covers the essential context: what it returns, which chains/tokens are supported, the payment mechanism, the data source, and how it connects to other tools. It does not detail return format, time window, pagination, or error behavior, but the included information is enough for an agent to call it correctly for most use cases.

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 80%, with chain, limit, token, and min_usd already documented with defaults and constraints. The description adds minimal parameter semantics beyond the schema, mostly reinforcing the multi-chain and token scope. The x_payment parameter is left undocumented in the schema, and the description only hints at it via the $0.01 x402 cost mention, which is useful but not a full explanation.

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 description states a specific resource: live whale alerts for large token transfers on Base/Ethereum, with a precise list of assets (USDC, WETH, cbBTC, USDT, WBTC) and output fields (USD value, amount, wallets, method, tx hash, age). It also distinguishes itself from sibling tools by explicitly naming the tools it chains into (smart_money_wallet_activity, wallet_portfolio), making the purpose unmistakable.

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 description provides clear usage context: it is a smart-money/whale-watching feed that trading and copy-trade agents poll to catch large transfers. It also positions itself as a Nansen-style alternative without a subscription and mentions related tools for follow-up. However, it does not explicitly say when NOT to use it or how it compares to other similar alert/activity tools.

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