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

Beyond the readOnly/idempotent annotations, it discloses the measurement's provenance (same number and source as the coin card's "median pull" line), the sample-size gates (percentiles null under 5 timed pulls with enough_data false; null under 30 for the table), and the declaration that N always travels in the answer. It even prescribes agent-facing phrasing when data is thin, which prevents malformed answers.

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 core definition is front-loaded in the first clause and each paragraph corresponds to one mode. It is dense but not padded, though the repeated restatement of N (three times across the text) is slightly redundant.

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?

With no output schema, the description still fully describes the return shape (median, p25, p75, N per window), null semantics, the enough_data flag, and the two output modes. For a 4-param, annotation-covered read tool this leaves nothing an agent needs unstated.

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 the baseline is 3, but the description adds real meaning: ca resolves to the dev who launched the coin, creator accepts 0x only with chain rh, and window is table-only with a 24h default. That clarifies interactions between params that the schema states only in isolation.

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 metric: the measured median time from first seen to the pull, with p25 and N, explicitly framed as a record rather than a prediction. An agent knows exactly what number it gets back. It never names or distinguishes itself against siblings like groundtruth_wallet_record or groundtruth_creator_replay, which probably surface overlapping creator/rug data, so it falls short of a 5.

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?

Routing is explicit: pass creator or ca for a single dev's median, pass nothing (or chain/window) for the chain and launchpad table. That is a clear use-when map for the tool's own modes. It gives no guidance about when to prefer this over a sibling tool, so it stops short of 5.

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