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

Without annotations the description carries the full burden, and it does disclose real behavior: default block window, maximum range, RPC filtering constraint, wallet-only fallback scanning known tokens, decoded amounts with decimals, and cost ($0.003 USDC). It says nothing about pagination, ordering, truncation when hitting the 5000-block cap, or error behavior, which leaves meaningful gaps for a paid log-scanning tool.

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 resource and decoded output, then constraints, then a concrete invocation example and price; dense but nearly every clause carries information. The example is useful but the 'token and/or wallet' phrasing coupled with a separate 'address' param adds slight ambiguity rather than trimming it.

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 9-parameter, zero-coverage, no-annotation, no-output-schema tool, the description covers the main path and gives one example, which is enough to attempt a correct call. It is not enough to call confidently on the range parameters, direction, limit, or the wallet/address distinction.

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 0% across 9 parameters, so the description must compensate and it only partly does. It explains token, chain, and the block window, but leaves limit vs blocks, from_block/to_block, and direction entirely undefined, and it never disambiguates the co-existing 'wallet' and 'address' parameters, which the example uses interchangeably as 'address' while the prose says 'wallet address'.

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?

Names a specific resource and verb ('ERC20 Transfer events'), the mechanism (eth_getLogs), the filter axes (token and/or wallet), and the decoded return fields (from, to, amount with decimals, tx hash, block), which separates it from siblings like chain_events, chain_erc20_balance, and chain_receipt.

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 concrete operating constraints: default window of last 100 blocks, hard cap of 5000, the requirement to pass token= on public RPCs, and the fallback that wallet-only queries scan known chain tokens. It stops short of naming sibling alternatives (e.g. chain_events for non-ERC20 logs), so no explicit when-not guidance.

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