groundtruth

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

Annotations already flag openWorldHint=true, idempotentHint=false and destructiveHint=false; the description adds real substance on top: orders lock in on arrival, fill on GT's captured curve, and incur the same fees as the bot. 'Paper only' resolves the biggest behavioral question (no real funds at risk). Gaps remain around re-entering an already-entered round and what 'out' does to an open position, so 4 rather than 5.

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 concept is front-loaded and the per-action clauses are dense but each carries information the agent needs. The closing 'Paper only. Not financial advice.' is slightly decorative, and the parenthetical parameter lists make it run-on, but nothing is materially wasteful.

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 9-parameter, nested-object, multi-action tool with no output schema, the description covers the action space, the trading mechanics and the paper-only nature, and hints at what 'state' and 'session' return. What it omits is the filter key meanings and any description of replay/session result shape, which matters given there is no output schema.

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 only 11% (just 'round'), so the description has to carry the load, and it largely does: it defines round as the coin mint, names size_sol, tp_pct, sl_pct, hold_s, delay_s, and even enumerates the filter keys (skip_red, skip_rap, min_holders, min_liq_sol, kol_in). What's missing is semantics for the 'session' integer, units/defaults for delay_s and hold_s, and the meaning of each filter, so it falls short of full compensation.

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 concrete subject (a paper-trading contest against SWAPNUTZ, GT's sniper, on pump.fun launches) and then enumerates all five actions with what each one does, so an agent knows exactly what the tool is. It does not explicitly contrast with any of the groundtruth_* analytics siblings, but the paper-trading framing is distinctive enough that confusion is unlikely.

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?

Each action is assigned a role and an implied sequence: 'state' lists open rounds and rules, 'in' enters one, 'session' reads a result, 'replay' backtests a strategy over 7 days of bot trades. That is clear use context. There are no explicit exclusions or 'use X instead' statements, which keeps it below 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 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?

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds genuinely new context: it is "Solana only", it is "Counts only" (no interpretation/handtyped data, GT_NO_HANDTYPED_V1), and it specifies the exact line format returned in lieu of an output schema. It does not discuss permissions, rate limits, or failure modes, but for a read-only counted-stat tool this is a solid addition.

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, but the body is one run-on sentence whose long inline output template (with unexplained placeholders like {r}, {vs}, {a}/{b}) dominates the text, and the important constraints ("Solana only. Counts only.") are buried at the very end. The template is load-bearing given no output schema, so the size is defensible, but the structure is hard to parse.

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 specialized statistics tool with no output schema, the description does the necessary work: it states the input context, the content of each returned count (creator rugged/launch window, wallet sell-before-rug rate, buy-hold rate, tape range), and the global constraints. An agent can call it correctly and interpret the return; depth of statistical meaning is left implicit but adequate.

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 only two parameters, each already documented as a Solana base58 value, so the schema carries the load. The description confirms the roles (the wallet being copied, the coin's launch as the reference point) but adds no syntax or format detail beyond what the schema 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?

The description frames the tool as producing the coin creator's counts and the wallet's counts (plus one formatted line) for a given wallet/coin pair, which is concrete and distinguishable in substance from siblings like groundtruth_creator_flag and groundtruth_wallet_record. However, it never uses a clear action verb ('returns'/'gets') and never names a sibling, so the agent must infer the operation from the output 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?

"For a copy bot about to follow a wallet into a coin" gives a real when-to-use context, which is better than nothing. There is no when-not guidance and no mention of the single-stat siblings an agent might use instead, so routing must be inferred.

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 the safe read-only/idempotent profile, yet the description adds substantial behavioral detail not in the structured data: live fields refreshed 'from the mint feed every 5 s', the staleness rule (refuse rows without mints_since_asof), the null-never-false semantics of known_bad, the distinction between recount-dated and live fields, and the *_proven false flags. That is exactly the kind of context annotations cannot carry.

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?

A single monolithic run-on paragraph that mixes purpose, output-field documentation, freshness semantics, census-rule caveats and warnings with no headings or ordering. The purpose is front-loaded in the first sentence, but everything after is an undifferentiated stream that an agent must parse word by word; many clauses exist to document return fields that have no output schema to live in.

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 full burden of explaining the return shape and largely does so: known_bad, rug rate, chain baseline, multiple, ttr_median/p25/mean with ttr_n and n_rugged, rugged_resolved/faded_resolved as x/y, plus the live fields. It is nearly complete, though the dense packing makes it easy to misread which fields are live versus historical.

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%: chain's enum/default and creator's address formats (base58 / 0x...) are already documented in the schema. The description's parameter-like sentences — the 'kol' block — describe output fields rather than either input, so it adds nothing for creator or chain. Baseline 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 does state what the tool returns in decision form: 'is this creator known bad, with the rug rate, the chain baseline and the multiple that justifies the verdict', and it differentiates from the wallet-list sibling ('use it when all you need is the decision rather than the wallet list'). However, this is buried under a wall of field-level jargon (TTR, asof, proven flags), and it does not distinguish itself from other creator-scoped siblings like screen_creator, creator_replay or scorecard. Clear purpose, weak sibling differentiation.

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?

There is explicit usage context — 'The cheapest call on this server -- use it when all you need is the decision rather than the wallet list' — which routes the agent away from the wallet-list tool. It also adds an operational rule ('A row with no mints_since_asof is not live: refuse it') and a warning that peak/pull/ttr are 'not a trade signal'. No other named alternatives or exclusion conditions are given.

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 cover only the safety profile (read-only, idempotent, open-world); the description carries all the substantive behavior: it defines the two returned rows, states held_to_end counts rugged launches as zero, explains that clock_upper_bound is a ceiling derived from the peak rather than a prediction, and discloses that launches lacking a recorded multiple are dropped from both stake and return.

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?

Front-loaded with the core purpose, then proceeds through the caveats in a logical order. It is dense and long, but for a measurement tool with no output schema nearly every sentence (ceiling vs measurement, exclusion rule, chain limit) earns its place; only mild redundancy holds it below 5.

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 fully discharges the burden of explaining return values (two named rows with their exact semantics), the exclusion rule that keeps both rows over the same set, quoting guidance, and the Solana-only limitation. An agent has what it needs to call and interpret it.

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 n, usd, and creator are already documented with types and defaults; the description adds only contextual framing ('last N resolved launches') and references output fields (computed_for, of) rather than enriching parameter meaning. 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?

States a specific verb+resource: it replays what a $100 stake would have returned across a creator's last N resolved launches. An agent can tell this apart from screening/scanning siblings because it is explicitly a retrospective per-creator replay, though it never names an alternative sibling to route away from.

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?

Usage is implied by the framing (evaluating a creator's historical launch performance) and constrained by the Solana-only caveat, but there is no explicit 'use this when / not when' guidance or reference to sibling tools that might be the better choice.

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 read-only, idempotent, open-world, non-destructive behavior, but the description adds meaningful context: free access is limited to the top 3 rows per list and list totals, while an API key (or /v1/kol over x402) unlocks every row. It also discloses that output contains wallets only and never names, and lists the data sources, which goes well 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 first sentence front-loads the core idea, but the rest is a dense run-on of sentence fragments and jargon that is hard to parse. It contains useful detail, yet the structure could be much cleaner and less repetitive without losing meaning.

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 tool's complexity, no output schema, and zero parameters, the description supplies substantial context: data sources, counted fields, free/paid tiering, and the no-names constraint. It still omits ordering, pagination, and any explanation of what 'list juice' or 'seconds to the pull' mean operationally, which keeps it from being fully complete.

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 the baseline is 4. The description does not need to explain parameter syntax, and it instead uses the space to describe the output fields (tag, launches, rugged/resolved, PULL, bonded, last mint, list juice), which is appropriate for a no-param tool.

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 and resource: it reports what KOL wallets launched and how those launches ended, with named metrics. It does not, however, explicitly differentiate itself from siblings like groundtruth_kol_feed or groundtruth_time_to_rug, leaving the agent to infer the 'board' framing from the tool name alone.

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?

There is no explicit when-to-use guidance or comparison to alternative tools. The phrase 'One call' hints that this tool is a single aggregated request, but the description never states when an agent should choose it over groundtruth_kol_feed, groundtruth_scoreboard, or similar siblings.

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 the read-only, idempotent, open-world, non-destructive safety profile. The description adds genuinely new behavioral context: the data lags ~10 minutes behind, free access returns only the newest 3 items, and an API key raises that to 30 with an x402 payment path. This is real disclosure beyond structured fields.

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 short and the access tiers are front-loaded at the end, but the prose is fragmented and cryptic ('Rugged of resolved', 'every count with its N'), which costs parsing effort. Not padded, but not cleanly structured either.

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 and no parameters, the description carries the burden and mostly succeeds: it explains the two data modes, staleness, and access limits. It would be stronger if it stated the return shape more plainly or contrasted with the sibling KOL tools.

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 per the rubric the baseline is 4. Nothing in the schema needs compensating, and the description's mention of 'One call' is consistent with a parameterless interface.

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 conveys the resource (a feed of KOL/top-profit wallet launches and their subsequent rugs) via the 'JUST IN' / 'AGAIN' breakdown, so the content is decipherable. However, the framing is jargon-heavy and elliptical ('Rugged of resolved', 'every count with its N'), and it never distinguishes this feed from the sibling groundtruth_kol_board or groundtruth_time_to_rug.

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 notes a free tier (newest 3) versus an API-key tier (30, or x402 over /v1/kol/feed), which is access guidance, but it gives no when-to-use-this-vs-alternatives direction and no exclusions. An agent cannot tell from this text why it would pick this feed over the KOL board or time_to_rug.

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, idempotent, non-destructive and open-world, so safety is covered. The description adds genuinely useful non-obvious traits: results are sorted by total rugs, each entry breaks down per-pad counts, and a 'PAD HOPPER OF THE DAY' entry is appended — an agent would not expect that extra non-ranked row from the schema. It does not cover result size or pagination behavior interacting with n. (Score reflects the additive return-shape detail against a high annotation baseline.)

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?

Roughly 60 words for a moderately complex board tool, front-loaded with the definition of a pad hopper. The middle sentence, 'Each leg = that pad's rugged of resolved, with its N,' is telegraphic to the point of ambiguity, which costs a point on structure even though nothing is padded.

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 optional parameter, no output schema, and annotations covering the safety profile, the description supplies what an agent actually needs: the population definition, the ranking rule, the per-pad breakdown, and the extra daily-highlight row. Terms like 'resolved' and 'N' remain unexplained jargon, a minor residual gap.

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% and the single parameter n is fully documented ('rows, 1-100 (default 25)'). The description adds nothing about n, but the baseline is 3 when the schema carries the parameter documentation.

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 resource with an exact qualifying criterion: developers who rugged on 2+ named launchpads, ranked by total rugs. The enumerated pad list and the leaderboard framing make it clearly distinct from siblings like groundtruth_scoreboard or groundtruth_kol_board. It lacks an explicit verb ('list'/'rank') at the front, keeping it 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?

Provides a routing cue to a sibling: 'groundtruth_creator_flag carries the same tag per dev (pads.hopper)' tells the agent to go there for per-developer lookups while this tool is the cross-pad board. No explicit exclusions or negative conditions are given, so it stops at clear context rather than 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.

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description adds real substance: the envelope's live block fields (last_mint_live, launched_live, bonded_live, mints_since_asof, ticker_asof), the KOL tagging payload, and the not_token response for dev wallets. It stops short of stating rate limits, caching, or failure modes for malformed addresses.

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 opening two sentences ('What the KOL wallet launched, and how it ended. Rugged of resolved, seconds to the pull, every count with its N.') are cryptic marketing fragments that consume prime front-loaded space before the actual purpose appears mid-paragraph. The later content is informative but dense and unordered, so the agent must parse past noise to find the operative statement.

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 burden of explaining returns, and it does so thoroughly: outcome label, liquidity/market-cap, holder counts, launch counts, the envelope's live block, and the not_token variant. Coverage of error paths and field-level semantics of the numeric counts is thinner than ideal, but an agent has enough to call and interpret it.

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?

With one parameter at 100% schema coverage, the schema already documents the address and supplies a worked example. The description restates the accepted formats (Solana mint / 0x contract) without adding syntax, validation, or normalization detail beyond what the schema provides, so the baseline 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 sentence 'Look up one token and return what GROUNDTRUTH counted about it' gives a specific verb and resource, and the enumeration of outcomes (rugged, died, graduated, survived) pins the domain. It also implicitly separates itself from wallet-oriented siblings by stating that a dev WALLET paste returns not_token plus a creator_record. However, it never names or contrasts an actual sibling tool, so the differentiation is indirect.

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 clarifies accepted inputs (Solana mint or Robinhood Chain 0x address) and the fallback behavior when a dev wallet is passed, which is genuinely useful routing guidance. But it gives no guidance on when to prefer this over groundtruth_screen_creator, groundtruth_creator_replay, or groundtruth_wallet_record, leaving the sibling-selection decision to inference.

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?

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds real value beyond that: unresolved calls are classified PENDING and never as wins, the denominator matters, and the tool also reports hash-chain integrity with an explicit instruction not to quote numbers if the chain is broken. That is substantive behavioral context.

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 the first sentence, but the prose wanders: 'resolved from the same data the card reads' and 'because the denominator is the point' are flavor that a terse tool description could drop. Four clauses for a one-parameter tool is heavier than necessary.

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 the work of explaining the return shape (bands, resolved vs PENDING, hash-chain status) and how to report it. That is close to complete, though the absence of any mention of the limit's effect on completeness of results leaves a small gap.

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?

There is a single 'limit' parameter at 100% schema coverage, so the schema already carries the semantics (rows to read, 1-500, default 200). The description adds nothing about pagination or how limit interacts with band grouping, so the baseline 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 states the resource (accuracy of calls stamped under the API key) and what it returns (groupings by band and by coin outcome), which is specific enough to distinguish it from a raw scoreboard. However, it never names or contrasts itself with the closest sibling, groundtruth_scoreboard, so an agent must infer the difference.

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 output-handling guidance ('report pending alongside resolved', 'if the chain is not intact, say so rather than quoting the numbers') but no when-to-use condition or alternative routing among the many sibling tools. Usage is implied rather than specified.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), but the description adds semantics they cannot: the exact decision rule for known_bad (published set AND >=5 resolved launches AND >=1.5x chain baseline) and the crucial null-vs-false distinction meaning 'not in our count'. That is real behavioral disclosure beyond structured fields.

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?

Front-loaded with the batch capability and the sibling alternative, and every sentence carries weight. The known_bad explanation is dense but justified since it encodes the core decision logic; slightly long, but not padded.

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 must describe what comes back — it does, listing each row field and explaining the known_bad tri-state. For a read-only batch screen, an agent has everything needed to call and interpret it.

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% with only two parameters, so the schema already documents chain enum, default, address formats, and the 200-item cap. The description reinforces the creator-address input but adds no syntax or format detail the schema lacks, making the baseline 3 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?

States a specific verb (screen), resource (creator addresses), and scope (up to 200 in one call), then enumerates the compact per-row outputs (launches, rug rate, chain baseline, multiple, wallet ties, operator collapse). It also explicitly differentiates itself from the sibling groundtruth_screen_creator, so an agent can pick between them 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 an explicit routing rule: 'Use this instead of calling groundtruth_screen_creator in a loop.' The batch boundary (up to 200) is stated up front, so the agent knows both when to choose this tool and when to fall back to the single-creator call.

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 only cover the safety profile (readOnly/idempotent/openWorld/non-destructive). The description goes well beyond them: it discloses the 5-second live-mint feed, freshness semantics (ticker_asof, mints_since_asof), that peak/pull and ttr_* are historical rather than trade signals, and that the tool 'does not say who owns the wallets'. With no output schema, this field-level behavioral context is exactly what the description must carry.

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 and most sentences carry signal, but the body is a single dense paragraph of domain jargon (ttr_*, bonded_asof, census rule) that is hard to parse, and the aside about rug rate versus baseline is editorial. Adequate but not cleanly 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?

With no output schema and a fairly complex analytic return, the description covers the returned fields, their live/historical status, truncation (schema notes wallets_truncated), and an explicit ownership caveat. It is close to complete, barring an explicit routing to the batch sibling.

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% across all four parameters, so the schema already documents role, chain, limit, and creator. The description adds little parameter-level detail (it even lists 'creator' as a role, which the schema enum does not allow as a filter), so the baseline 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?

States a specific verb and resource: 'Given one creator address, return every wallet that was early in that creator's launches', plus the enrichment dimensions (role, early-count, rug rate vs baseline). The single-creator scope implicitly separates it from the sibling groundtruth_screen_batch, but no sibling is named explicitly.

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?

Usage context is only implied by 'Given one creator address' — there is no explicit when-to-use, when-not, or pointer to groundtruth_screen_batch for multi-creator screening. The 'A row with no mints_since_asof is not live: refuse it' line is a useful data-handling rule but not a selection guideline.

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 cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), and the description adds the important behavior annotations cannot express: the row is hash-chained to the previous one and cannot be edited or removed after resolution. It omits auth/permission requirements and rate-limit behavior, but the immutability disclosure is substantial context.

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?

Four sentences, front-loaded with the core action and closing with the return value, all of which earn their place. The aphorism about remembered wins adds motivating context at the cost of a little length.

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 state what comes back (row hash and sequence number), and it covers the immutability guarantee and the obligation to stamp every call. Given 80% schema coverage and one required parameter, an agent has enough to invoke it correctly; only auth and chain-selection semantics are left implicit.

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 80%, so the schema already documents the five parameters, and the description adds no per-parameter detail such as what 'ca' must be or how 'band' relates to 'rule_id'. Baseline 3 is appropriate when the schema carries the parameter 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 uses a concrete framing — stamp a verdict before the outcome so it can be counted later — and names the return payload (row hash and sequence number), so the agent knows this is a write of a pre-resolution call record. It never names a sibling explicitly, so it does not fully differentiate itself from groundtruth_scorecard or groundtruth_scoreboard despite hinting at the scorecard concept.

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 clear when-to-use guidance: 'Stamp every call you make, including the ones you are confident about,' with a rationale against survivorship bias. It does not name an alternative tool or state when not to use this one, so it 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.

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.

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

Annotations already mark this as read-only, idempotent, open-world, and non-destructive, so the safety profile is covered. The description adds substantial behavioral context beyond annotations: data provenance from a capture tape, exclusion of self-created coins, null conditions, live-field freshness, and a rule to refuse rows without mints_since_asof.

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 a single dense paragraph with long parenthetical definitions and many specialized terms. It front-loads the core idea but then becomes difficult to parse, and much of the field-level detail could be structured more cleanly or moved to an output schema.

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 must carry the full burden of explaining return values and behavioral conditions. It does so extensively, covering the four count fields, denominator definitions, rate comparisons, null behavior, tape range, role labels, live fields, and refusal conditions.

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 wallet parameter is already documented as a base58 Solana address. The description adds meaningful context by explaining the wallet must be in the tape cut (at least 100 buys) or wallet_record is null, which the schema does not state.

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 that one wallet goes in and its counts come out, names the data source (GROUNDTRUTH's Solana capture tape), and enumerates the returned fields. It does not differentiate this tool from any sibling tool by name or scope, but the core purpose is specific enough for an agent to identify it.

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?

Usage is implied by 'One WALLET in, its counts out,' and the description notes that wallet_record is null when the wallet is outside the tape cut (fewer than 100 buys). It gives no explicit when-to-use guidance versus sibling tools and no alternatives for wallet-level queries.

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?

Goes well beyond the annotations by disclosing data freshness (5-minute lag on free tier), auth/key requirements, per-call pricing, and the exact payload the caller gets. The value is real, but the internal inconsistency about whether a key is required undercuts an agent deciding how to authenticate.

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, but the text is a single dense run-on mixing feature list, an internal monologue about JSON-RPC, three pricing tiers, attribution legalese, and a contradictory key note. Several clauses (not a JSON-RPC endpoint, source: Data: GroundTruth, counts only wallets only) don't help an agent call the tool.

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 two-parameter read feed with no output schema, it covers the returned fields, freshness, and access tiers thoroughly. Gaps are minor: no pagination/cursor behavior, no ordering guarantee, and the key-requirement ambiguity is left unresolved.

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 both parameters (n, chain) are already described in the schema with defaults and enum values. The description adds nothing about limiting, chain selection, or result ordering, so baseline 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?

States the resource precisely: newest token launches on Solana and Robinhood Chain, each annotated with the dev's prior-launch history (rug count, median pull, last launch, bonded count). The 'RPC-style stream... not a JSON-RPC endpoint' framing is confusing and never differentiates it from siblings like groundtruth_kol_feed or groundtruth_kol_board, so the agent still has to guess which feed to pick.

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 pricing/tier context (FREE 5 min delayed, x402 per-call live, $99/mo push) which implies when the tool is affordable, but it never says when to prefer this over sibling feeds or screening tools. It also contradicts itself on auth: 'no key on GET /v1/launches' vs. the closing 'This tool needs a key.'

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 annotations already declare read-only, idempotent, open-world, non-destructive behavior. The description adds useful context beyond annotations: the data source is the Polygon chain, each market shows fresh-or-clustered money concentration with wallet counts and HEAT scores, and it includes a pre-start stamp hash. It also states it is information only, not financial advice.

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 core purpose and then packs several useful return-field details into a single paragraph. It is dense and jargon-heavy, but lacks filler and every sentence adds relevant context.

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 and no parameters, the description does a good job listing the per-market fields an agent will see, including side, dollar and wallet counts, price, HEAT score, and stamp hash. Some field names like 'k of N' and 'HEAT 0-100 with its N' remain slightly opaque, but the overall scope is sufficiently complete.

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 input parameters, so there is no parameter semantics to explain. The baseline score for zero parameters is 4.

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 resource and content: a LINE CHECK board for prediction-market line buying, covering Polymarket games in the next 72 hours and the US midterm race board. It is specific about what data is shown per market, though it does not explicitly differentiate itself from sibling tools like market_heat.

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 scope details (next 72 hours, midterm race board) but never states when an agent should choose this tool over alternatives or when not to use it. No sibling tools are named or compared.

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, idempotent, openWorld, and non-destructive behavior. The description adds useful behavioral context: the ranking methodology, the $1,000 real-money threshold, and the null-with-reason outcome when no qualifying market exists. It does not mention authentication or rate limits, but those are less critical for a read-only metric.

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 core purpose and is reasonably sized, but the phrase 'with N.' is cryptic and unexplained, disrupting structure. The nested parentheticals make the single long sentence dense, though most content 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?

With no output schema, the description should fully explain return values. It states that heat is 0-100 or null with a reason, which is helpful, but it does not clarify whether results are per side or how the response is structured, and 'with N.' remains undefined. For a one-parameter read-only tool this is adequate but incomplete.

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% for the single 'cid' parameter, which is documented as a Polymarket condition id in 0x + 64 hex format. The description reinforces 'condition id' but adds no syntax or semantic 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 states a specific metric (HEAT) for a specific resource (one Polymarket market) and defines the metric as the share of a side's $ from fresh or clustered wallets, ranked 0-100. It is clear what the tool returns, but it does not explicitly distinguish itself from any sibling 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?

There is no guidance on when to use this tool versus alternatives, nor any stated prerequisites beyond the condition id format already in the schema. The disclaimer 'Information only, not financial advice' is not usage guidance.

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