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

Annotations already declare readOnly/destructive/openWorld/idempotent, but the description adds substantial context beyond them: cost model ($0.01/call via x402 or card key, first 25 free, failed calls free), the 400 rejection for malformed addresses being uncharged, and the warning that repeats are not free because each call is billed. That billing/repeat-charge nuance is exactly the kind of behavior an agent needs and cannot get from annotations.

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 purpose, scope, alternative, then pricing; the example address earns its place as a format anchor. Slightly redundant on cost, which is mentioned twice ('first 25 free; failed calls free' and 'each call is charged, so repeats are not free'), but the density is justified for a paid tool.

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?

There is no output schema, and the description compensates by naming the returned fields (direction, counterparty, amount, transaction), ordering (newest first) and row cap (up to 50). No output schema leaves nothing critical unspecified for an agent to call this correctly.

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 all three parameters including defaults and ranges are already documented in structured form. The description restates the USDC default and the 1–2,000 block window, and adds a concrete example address, but adds no semantics (e.g. how block window interacts with the 50-result cap) beyond the schema. Baseline 3 is appropriate.

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 ('List') and resource ('recent transfers of one ERC-20 token ... on Polygon PoS') with scope details (in/out, block window, default USDC, cap of 50, sort order). It explicitly contrasts itself with polygon_token_balance, so an agent can separate it from the balance sibling without opening either 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?

Gives concrete usage scenarios ('confirm a payment arrived or see what was sent') and names the alternative tool with the condition that selects it ('for the current balance use polygon_token_balance'). The when-to-use and when-to-use-something-else paths are both explicit.

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