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

Annotations already declare readOnly, idempotent, non-destructive and open-world. The description adds real behavioral scope limits ('Solana only', 'Counts only' – no advice), which is useful and not redundant with the annotations. It stops short of covering auth, rate limits, or latency.

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?

It is effectively one sentence, front-loaded with the intended user ('a copy bot about to follow a wallet'), which is good. But the embedded example line is long, jargon-dense and hard to parse, so the structure favors information volume over readability.

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, so the description carries the return-value burden — and it does describe the output well, spelling out the one-line format with creator verdicts, wallet counts and a tape date range. Combined with 'Solana only, counts only' scope notes, this is close to complete for a read-only counting tool.

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% and both params (ca as Solana mint, wallet as Solana base58) are documented in the schema. The description's mention of 'creator counts' and 'wallet's counts' loosely maps to the two inputs but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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 identifies a specific use case (a copy bot following a wallet into a coin) and the artifacts it returns (creator counts, wallet counts, one summary line). However, it never states a clean verb+resource, is buried in domain jargon ('capture tape', 'SAME HAND'), and does not distinguish itself from siblings like groundtruth_creator_replay or groundtruth_wallet_record.

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 opening 'For a copy bot about to follow a wallet into a coin' implies the decision context in which this tool applies, so usage is inferable. But there is no explicit when-not guidance and no mention of alternative sibling tools for adjacent questions.

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