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

Annotations already declare read-only and open-world behavior. The description adds important context beyond the annotations: the call costs $0.05 in USDC via x402, payment happens inside the tool call, and failed calls aren't charged. It does not describe output shape or pagination, but no output schema exists and the analytics content is summarized.

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 purpose is front-loaded in a concise opening question, followed by scope, use case, and pricing. The pledge sentence is slightly tangential to invocation but still brief and relevant to seller transparency; overall it is efficient and well structured.

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 read-only, two-parameter analytics tool with no output schema, the description covers what is analyzed, when to use it, cost, and failure charging. It could be stronger by clarifying the return format or how results relate to the `days` window, but the major invocation-relevant facts are present.

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 100%, so `address` and `days` are already documented in the input schema. The description reinforces that `address` is the seller pay-to address on Base and implies weekly cohort lookback, but adds no syntax or format detail 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?

The description states a specific resource and analysis: payer analytics for an x402 seller from USDC payments on Base, including repeat buyers, one-off payers, revenue per payer, and weekly retention cohorts. It is clear what the tool does, but it does not explicitly distinguish itself from the sibling `buyer_panel`, which sounds adjacent.

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?

It gives an explicit use condition: "Use when an agent needs payer analytics for a pay-to address." That is clear context, but it does not state when not to use it or name a specific alternative sibling such as `buyer_panel`, so the guidance stops short of full routing.

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