groundtruth

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

Annotations already declare the tool read-only, idempotent, and non-destructive; the description adds contextual behavior by clarifying that it returns only available days, not the autopsies themselves. It also reveals the public URL convention for retrieving a particular autopsy. This complements the annotations without contradicting them.

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?

Three short sentences each have a distinct job: declare the resource, explain what an autopsy is, and tell the agent how to act on the returned days. It is front-loaded and contains no filler.

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 parameterless read-only index, the description fully explains what is returned ('available days') and the next step for fetching content. The absence of an output schema is offset by the explicit statement of the return value.

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?

The tool takes zero parameters, so there are no parameter semantics that the description needs to clarify. The description instead conveys the relevant index behavior, which is sufficient for calling the tool correctly.

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 opens with the precise action: 'List the dated autopsies GROUNDTRUTH has published,' identifying the verb, resource, and scope. It further defines what an autopsy is, so an agent can distinguish this index from the sibling census/scoreboard tools without inspecting schemas.

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 states that this is an index of available days and directs the agent to '/autopsy/<day>' for a specific writeup, giving a clear follow-up path. It does not enumerate sibling alternatives, but none of the listed siblings is a specific-autopsy fetcher, so no exclusions are needed.

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

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

Annotations already cover readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds meaningful context beyond the annotations by clarifying that this is captured market data rather than exhaustive historical coverage, and by noting the generation timestamp. No contradiction with annotations exists.

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 description is two sentences with no filler. The main action and contents are front-loaded, and the caveat about baseline-only usage is placed at the end without redundant elaboration.

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 zero-parameter, read-only, idempotent tool with no output schema, the description is complete: it states what is returned, the data scope, and the appropriate use case. An agent has everything needed to invoke the tool correctly and interpret its output at a high level.

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?

The tool has zero parameters and the schema description coverage is 100%, so there is no parameter documentation burden. The baseline for a zero-parameter tool is 4, and the description appropriately spends no space on parameters.

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 opens with a specific verb and resource: 'Return the corpus-level figures the site publishes,' then enumerates exactly what is included: launches captured per chain, resolved counts, shares that rugged/died/survived/graduated, and the generation timestamp. This level of specificity makes it clearly distinguishable from sibling tools that focus on per-creator or per-scan operations.

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 description provides explicit usage guidance: 'use it for baselines, not for totals of all activity' and warns that the data is 'not exhaustive coverage from a start date.' This gives the agent a clear positive and negative condition for when to invoke this tool rather than similar data tools.

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

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

The description adds meaningful behavior beyond the annotations: known_bad is null and never false for unknown creators, the underlying data is a batch export with a freshness lag, and each response carries its generation timestamp. These are valuable details for interpreting results correctly.

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 description is compact yet information-dense, front-loading the core purpose before adding usage guidance and edge-case semantics. Every sentence contributes: what it returns, when to use it, the null convention, data staleness, and response timestamp.

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 simple two-parameter lookup with no output schema, the description covers the response fields, the null semantics, the data freshness caveat, and the use case. This is enough for an agent to invoke the tool and interpret the result correctly without additional context.

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 the schema already explains the creator and chain parameters clearly. The description does not add new input-parameter meaning; it focuses on output semantics and usage context, so the baseline of 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 query-and-answer behavior: given one creator, it returns a known-bad verdict plus rug rate, chain baseline, and the justifying multiple. It also distinguishes itself from siblings by emphasizing it is the cheapest call and returns a decision rather than a wallet list.

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 explicitly says to use this tool when all you need is the decision rather than the wallet list, which provides clear selection guidance versus sibling tools. It also discloses the batch-export freshness limitation, telling agents not to rely on it for creators launched in the last hour.

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

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

The description goes far beyond the readOnly/idempotent annotations. It carefully distinguishes held_to_end as a MEASUREMENT vs clock_upper_bound as a CEILING, explains rugged launches are counted as zero, notes launches without a recorded multiple are excluded from both stake and return, and flags the Robinhood data limitation. It also warns how to quote the ceiling ('Say at most'), which is genuinely useful behavioral guidance.

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 description is dense and long, but nearly every sentence earns its place by adding a semantic caveat or scope limitation. It front-loads the core purpose and output shape before diving into measurement/ceiling distinctions. It could be broken into clearer bullets, but it is not padded or 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 carries the burden of explaining return semantics, and it does so thoroughly for held_to_end and clock_upper_bound. It also covers exclusions and platform limitations. Minor gaps remain: 'band p25' is not defined, and computed_for/of are referenced without explaining what they contain, so an agent may still be slightly uncertain about the exact output row fields.

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 schema already defines n, usd, and creator with defaults and types. The description contextualizes these parameters inside the $100 and 'last N resolved launches' scenario but adds no new parameter-level constraints or format details beyond the schema. The 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 opens with a concrete scenario: 'What $100 would have done across a creator's last N resolved launches.' It also states the output shape ('Returns two rows'), so an agent can tell this is a historical replay/backtest tool. It does not name a sibling alternative or explicitly distinguish itself from tools like groundtruth_scorecard, so it stops 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?

The description implies usage: call this when you need a historical '$100 stake' replay across a creator's resolved launches)Skip it for unsupported platforms. It gives a platform constraint ('Solana only today') but never states when to prefer this over siblings or when not to use it. The usage context is mostly implied rather than explicit.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds useful behavioral context by calling it 'the same read the public site performs' and indicating it returns recorded history, which helps the agent understand expected side effects and data freshness.

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?

Three concise sentences with no filler: the first declares the action and return fields, the second states accepted input formats, and the third grounds it in a familiar public-site behavior. Every sentence earns its place and key info is front-loaded.

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 one parameter and no output schema, the description sufficiently covers what the tool does, what input it takes, and what data will be returned, including the possible 'no outcome recorded' label. No critical call-time detail is missing.

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 for the only parameter is 100%, so the schema already documents accepted formats and provides an example. The description reinforces the accepted address types but adds no additional semantic meaning beyond what the schema already states, meeting the baseline.

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 action (look up one token) and resource (GROUNDTRUTH records), and enumerates exact returned data: outcome label, liquidity, market cap, holder counts, and launcher wallet. It explicitly distinguishes itself as a single-token lookup, which separates it from batch/screen siblings.

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?

Clear context is provided: this is for a one-token lookup, accepting either Solana mint or Robinhood Chain address, and it matches what the public site does when pasting a contract. It does not explicitly name alternatives or when-not-to-use cases, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds context beyond annotations by noting the scoreboard is 'public' (implying no auth barrier) and describing what data it exposes, which helps an agent set expectations.

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?

Two sentences with no filler: the first front-loads the action and data content, the second states the use case. Every sentence earns its place.

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 0-parameter, read-only tool with no output schema, the description conveys what the response will contain (call counts, resolutions, resolution types) and why an agent would call it. The absence of an exact output format is a minor gap, and the scorecard sibling is not disambiguated.

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?

The tool has 0 parameters, so the baseline is 4. The description correctly implies no arguments are needed and focuses instead on the returned content, so nothing is lost.

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 verb ('Return') and resource ('public accuracy scoreboard') and enumerates the content: forward calls made, resolved count, and how they resolved. However, a sibling named groundtruth_scorecard exists, and the description does not clarify how scoreboard differs from scorecard, leaving some selection ambiguity.

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 second sentence gives explicit guidance for when to use the tool: to judge how much weight to give the other GROUNDTRUTH tools. It does not name alternatives or state when not to use it, but the context is clear enough for an agent.

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

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

The description richly supplements the readOnly/openWorld/idempotent annotations by disclosing the PENDING semantics, the dependency on the coin's resolution status, and the hash-chain integrity behavior. It also tells the agent what to do conditionally, which is valuable beyond the 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?

The description is tight and front-loaded, with the core purpose in the first sentence. Every sentence adds meaningful behavioral or reporting detail, and there is no redundant filler.

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 adequately explains the returned information: grouped accuracy rates, pending handling, and hash-chain status. It is slightly light on defining 'band' or what 'right' means in concrete terms, but overall it is complete enough for a single-parameter 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?

The only parameter, limit, is fully described in the schema with range and default. The tool description adds no additional parameter semantics, so a baseline score of 3 is appropriate given 100% schema coverage.

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 clearly states the tool's purpose: measuring how often sealed calls were right, grouped by band and actual coin outcome. It names a specific resource and metric, but does not explicitly distinguish itself from the sibling groundtruth_scoreboard or other similar tools.

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 description gives strong interpretive guidance—report pending alongside resolved and don't quote numbers if the hash chain is broken—but it does not state when this tool should be preferred over its siblings. No alternatives or exclusion conditions are mentioned.

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

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

Beyond the annotations, the description discloses critical behavior: known_bad is true only under a specific combination of conditions, and it is null, never false, for unknown creators. This 'absence is not innocence' framing adds important interpretive context that annotations cannot convey.

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 description is compact and every sentence earns its place: the first defines the tool's batch capability and output, the second gives the direct sibling alternative, and the third clarifies the nuanced known_bad flag. It is front-loaded with the most important operational facts.

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?

The description covers the major invocation context: batch scope, output row fields, sibling routing, and the interpretation of known_bad. With no output schema present, the row-field list helps, though some domain terms such as 'apparent-versus-true operator collapse' remain unexplained and would benefit from a brief definition or example.

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 the schema already documents both parameters and the maxItems limit. The description adds context about the batch-oriented purpose and the known_bad decision logic, but not additional parameter-level syntax or format details.

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 uses a specific verb and resource: 'Screen up to 200 creator addresses in ONE call'. It clearly states the output shape, compact rows with named fields, and explicitly differentiates this from the sibling groundtruth_screen_creator by saying to use this instead of looping over that tool.

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 description explicitly says 'Use this instead of calling groundtruth_screen_creator in a loop.' This directly communicates when to choose this batch tool over the sibling single-creator tool, giving the agent a clear routing decision.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is known. The description adds meaningful behavioral context beyond that: it explains that wallets with near-identical launch histories are merged, that rates include a chain baseline, and that the tool intentionally exposes the independent-looking versus distinct-actor collapse. These are valuable non-obvious behaviors.

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 description is long but packed with substantive detail, and it front-loads the core purpose in the first sentence. Each clause adds a specific piece of the output contract, and the final sentence, while slightly promotional, reinforces uniqueness rather than repeating structured fields.

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 does a good job explaining what the response contains: roles, early-launch counts, rug rate, baseline, and actor-collapse metrics. It omits some structural details like exact result shape or truncation behavior, but the schema's limit parameter already covers truncation reporting, and the existing coverage is sufficient for an agent to know when and how to call the 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%, so the schema itself already documents creator, role, chain, and limit. The description adds conceptual color around 'early' and the analytical outputs, but does not add parameter-level meaning beyond what the schema gives. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 names a specific verb ('return'), a precise resource (wallets early in a given creator's launches), and enumerates the exact analytical output: roles, early-launch counts, rug rate, and apparent-versus-true wallet collapse. This differentiates it decisively from sibling tools like groundtruth_scan_coin or groundtruth_scorecard, and the closing claim that this is 'the analysis no other source produces' reinforces its unique purpose.

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 'Given one creator address' establishes a clear and concrete trigger for when to call this tool. It does not explicitly name alternative siblings or state when not to use it, but the described one-creator scope and unique outputs provide a strong contextual cue that separates it from batch or index tools.

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

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

The description discloses critical behavior beyond the annotations: rows are hash-chained under the API key, verdicts cannot be edited or removed after resolution, and the tool returns the row hash and sequence number. The annotations only indicate non-read-only, non-idempotent, non-destructive, so this added context is genuinely valuable and non-contradictory.

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 description is front-loaded with the most important timing constraint and each sentence adds meaningful context: what the tool does, how integrity is enforced, when to use it, and what is returned. The motivational sentence about scorecards is slightly extra but reinforces appropriate usage.

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?

Given the absence of an output schema, the description appropriately includes the return value (row hash and sequence number). It covers timing, immutability, keying, and usage expectations. Combined with the rich input schema, the agent has enough information to invoke the tool 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 description coverage is 80%, so the schema already explains most parameters. The description does not add parameter-level detail, but it does clarify the overall concept of a 'verdict' and the honesty mechanism, which helps an agent understand why ca, band, and rule_id are relevant. This matches the baseline for high schema coverage.

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 clearly states the specific action ('Seal a verdict BEFORE the outcome exists') and the resource (a call/verdict), and explains the purpose: enabling later scoring while preventing post-outcome tampering. This distinguishes it from sibling tools like scan, scoreboard, or scorecard without needing to open their schemas.

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 description gives explicit timing guidance ('BEFORE the outcome exists') and strong direction to use this tool for every call, including confident ones. It does not explicitly name alternative tools or exclusion cases, but the context is clear enough that an agent should seal all calls.

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

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

Even with readOnly/openWorld/idempotent annotations, the description adds valuable behavior: the denominator definition, the 30-call threshold, null percentiles, enough_data=false, and the requested phrasing. This goes well beyond the annotations and leaves the agent prepared for edge cases.

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 first sentence front-loads the core statistic and scope, and every sentence adds information. It is slightly dense but not padded; the threshold guidance could be tighter, but it earns its place.

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 stats tool with no output schema, the description conveys units, quantiles, denominator, data-sufficiency rule, and table mode. It stops short of spelling out the exact answer shape/fields, but it is complete enough for correct invocation.

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 enums and descriptions, so baseline is a 3. The description adds the omit-every-argument aggregate mode and clarifies that arguments select one chain/band/window, which is additional parameter-level meaning.

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 clearly states the tool computes median/p25/p75 time-to-rug for coins in a risk band, scoped by chain/band/window. It is not vague, but it does not name or contrast any sibling tool (e.g. groundtruth_scan_coin), so it misses the differentiation that earns 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?

It explicitly says 'Use it to answer "how long would I have had"' and instructs omitting all arguments for the full table. It provides clear context but no explicit when-not-to-use or alternative routing to sibling tools.

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