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

Annotations already cover the safety profile (readOnly, openWorld, non-idempotent), and the description adds real context beyond them: the price ($0.10 USDC per call), the payment mechanisms (x402 or prepaid credits), and that it is excluded from the free trial. It says nothing about rate limits or response freshness, but the added billing/auth context is substantive.

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?

Purpose is front-loaded in the first clause, followed by the enumerated drivers, then chains, example, alternative, and pricing. It is somewhat dense and stacks multiple ideas (pricing, chains, example) into one paragraph, but every sentence carries information an agent can use.

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?

An output schema exists so return values need no explanation, and the description covers chains, pricing, payment path, and the deep-narrative alternative. The main remaining gap is not distinguishing this tool from the broader token-report/token-price family, which would round out selection guidance.

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% with two well-documented params, including the chain enum and address format, so the baseline is 3. The description restates 'address: ..., chain: base' as an example but adds no syntax, format, or default nuance beyond what the schema already provides.

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+scope: 'What happened to this token in the last 24 hours, and why' with an enumerated breakdown (price path, volume, flow, whale moves, unlocks, news, safety). It also differentiates itself from the sibling token-24h-deep by naming the narrative variant, so an agent can route 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 clear context (24h activity diagnosis across 8 named chains), points to the alternative when a narrative is wanted ('With an AI narrative: /token/24h/deep'), and states the paid-only constraint. It doesn't explicitly state when this is preferable to token-price, token-report, or token-whales, so it falls short of full when/when-not guidance.

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