Dev records, pump.fun + Robinhood Chain: launches, rugs, bonded, live last mint. Every figure has N.
Scored across 15 tools
Four tools (creator_flag, kol_board, kol_feed, scan_coin) open with the identical verbatim sentence 'What the KOL wallet launched, and how it ended. Rugged of resolved, seconds to the pull, every count with its N. One call.', making them hard to tell apart at a glance. Creator-level tools (creator_flag, creator_replay, screen_creator, screen_batch), wallet-level tools (wallet_record, copycheck, scan_coin), and accuracy tools (scoreboard, scorecard) heavily overlap in inputs and outputs, so misselection is likely despite long prose distinguishing them only on close reading.
Every tool uses the same groundtruth_ prefix and snake_case noun-style names (autopsy_index, creator_flag, kol_board, wallet_record), which is highly predictable. The lone deviation is 'copycheck' rendered as a single word rather than snake_case like the rest.
15 tools is a reasonable upper-bound for a domain spanning coins, creators, wallets, KOL tracking, and accuracy accounting. It is slightly heavy, and one slot (time_to_rug) is occupied by a withdrawn tool that now returns only nulls and a withdrawn flag.
The surface covers strong lifecycle coverage: single-coin lookup, batch and single creator screening, wallet records, KOL boards/feeds, call sealing, and both public and per-key scorecards. Gaps are minor but real — time_to_rug is withdrawn (leaving no working timing primitive), and the Robinhood chain has stated holes in outcome data.
List the dated autopsies GROUNDTRUTH has published. Each is a writeup of one launch and what happened to it. Returns the available days; fetch a specific one from the public site at /autopsy/.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Return the corpus-level figures the site publishes: launches captured per chain, how many resolved, and the share that rugged, died, survived or graduated, with the generation timestamp. This is market data GROUNDTRUTH has captured, not exhaustive coverage from a start date -- use it for baselines, not for totals of all activity.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
For a copy bot about to follow a wallet into a coin: the coin's creator counts (to that coin's launch when we have them), the wallet's counts from the capture tape, and one line built from those counts only, e.g. "creator: SAME HAND 12/12 RUGGED (counted to this coin's launch) · wallet: 393/1,241 sells within 60 s before a rug, below the all-wallet rate · 701/2,450 buys where a wallet that first bought 1-2 s later still held at the rug, below the all-wallet rate · ... · tape 2026-08-29..2026-09-28". Solana only. Counts only.
| Name | Required | Description | Default |
|---|---|---|---|
| ca | Yes | The coin (Solana mint, base58). | |
| wallet | Yes | The wallet being copied (Solana, base58). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world. The description adds real behavioral scope limits ('Solana only', 'Counts only' – no advice), which is useful and not redundant with the annotations. It stops short of covering auth, rate limits, or latency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is effectively one sentence, front-loaded with the intended user ('a copy bot about to follow a wallet'), which is good. But the embedded example line is long, jargon-dense and hard to parse, so the structure favors information volume over readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the return-value burden — and it does describe the output well, spelling out the one-line format with creator verdicts, wallet counts and a tape date range. Combined with 'Solana only, counts only' scope notes, this is close to complete for a read-only counting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both params (ca as Solana mint, wallet as Solana base58) are documented in the schema. The description's mention of 'creator counts' and 'wallet's counts' loosely maps to the two inputs but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific use case (a copy bot following a wallet into a coin) and the artifacts it returns (creator counts, wallet counts, one summary line). However, it never states a clean verb+resource, is buried in domain jargon ('capture tape', 'SAME HAND'), and does not distinguish itself from siblings like groundtruth_creator_replay or groundtruth_wallet_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening 'For a copy bot about to follow a wallet into a coin' implies the decision context in which this tool applies, so usage is inferable. But there is no explicit when-not guidance and no mention of alternative sibling tools for adjacent questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What the KOL wallet launched, and how it ended. Rugged of resolved, seconds to the pull, every count with its N. One call. kol: when the creator is on a public KOL list (kolscan, the pump.fun leaderboard, kolscan.fun, KolHood, Kolosseum) -- tag KOL or TOP PROFIT, the lists, tg / x / verified as yes-no, the list rank, listed now; null when it is on none. Never a name or handle. One creator in, one small answer out: is this creator known bad, with the rug rate, the chain baseline and the multiple that justifies the verdict. Also returns TTR -- ttr_median, ttr_p25 and ttr_mean, in seconds from launch to rug over this creator's rugged launches, with ttr_n and n_rugged -- and rugged_resolved / faded_resolved as x/y, all counted to the build time of the data and from launch outcomes only. The cheapest call on this server -- use it when all you need is the decision rather than the wallet list. known_bad is null, never false, for a creator not in our count. The counts are a batch recount; LIVE FIELDS, from the mint feed every 5 s: last_mint_live (unix s of the dev's newest mint), launched_live, bonded_live and mints_since_asof; ticker_asof = the newest mint the feed has seen. A row with no mints_since_asof is not live: refuse it. bonded_asof dates the recount part; peak / pull and ttr_* are history (peak_proven / pull_proven false), not a trade signal; known_bad is the census rule.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Which chain the creator launched on. | solana |
| creator | Yes | Creator address. base58 for Solana, 0x... for Robinhood Chain. |
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.
What $100 would have done across a creator's last N resolved launches. Returns two rows. held_to_end is a MEASUREMENT: the recorded multiple at the end of each launch, with rugged launches counted as zero because the liquidity was pulled. clock_upper_bound is a CEILING, not a prediction: it uses the recorded PEAK multiple and only where the peak arrived at or before the band p25, because the published data carries the peak and the final multiple, not the path between them. Say "at most" when you quote it. Launches with no recorded multiple are excluded from BOTH the stake and the return, so the two describe the same set -- quote computed_for and of, never just the total. Solana only today: the Robinhood outcome data carries no peak multiple, so neither row can be computed there.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | how many of the most recent resolved launches, 1-12, default 10 | |
| usd | No | the stake per launch in dollars, default 100 | |
| creator | Yes | the creator wallet (base58) |
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.
What the KOL wallet launched, and how it ended. Rugged of resolved, seconds to the pull, every count with its N. One call. The wallets on kolscan, the pump.fun leaderboard, kolscan.fun, KolHood and Kolosseum that launched coins, counted by GROUNDTRUTH: tag KOL or TOP PROFIT, launches, rugged / resolved, PULL, bonded, last mint, and list juice (Telegram / X / verified as yes-no, list rank, listed now). Wallets only, never a name. Free: the top 3 per list and every list total; with an API key, every row (or /v1/kol over x402).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
What the KOL wallet launched, and how it ended. Rugged of resolved, seconds to the pull, every count with its N. One call. JUST IN: launches by wallets on the KOL and top-profit lists, newest first, each with that wallet's rugged / resolved before it; AGAIN: rugs on their coins with the seconds to the pull. 10 minutes behind. Free: the newest 3; with an API key, 30 (or /v1/kol/feed over x402).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
What the KOL wallet launched, and how it ended. Rugged of resolved, seconds to the pull, every count with its N. One call. When the dev is on a KOL list, envelope.kol carries tag KOL / TOP PROFIT, the lists, yes-no flags and rank (never a name). Look up one token and return what GROUNDTRUTH counted about it: the outcome label (rugged, died, graduated, survived, or no outcome), liquidity and market-cap figures, holder counts, and the launch counts of the wallet that launched it. Accepts a Solana mint or a Robinhood Chain 0x contract address. This is the same read the public site performs when someone pastes a contract address. The answer carries the envelope; its live block holds the dev's last_mint_live, launched_live, bonded_live, mints_since_asof and ticker_asof (the newest mint the feed has seen). A dev WALLET pasted here answers not_token plus that dev's creator_record and the same live fields.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | A Solana mint (base58) or a Robinhood Chain contract address (0x...). Example: So11111111111111111111111111111111111111112 |
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.
Return the public accuracy scoreboard: how many forward calls GROUNDTRUTH has made, how many have resolved, and how those resolved. Use this to judge how much weight to give the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
How often calls stamped under this API key were right. Groups them by band and by what the coin actually did, resolved from the same data the card reads. A call whose coin has not resolved counts as PENDING, never as a win -- report pending alongside resolved, because the denominator is the point. Also returns whether the hash chain is intact; if it is not, say so rather than quoting the numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | rows to read, 1-500, default 200 |
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.
Screen up to 200 creator addresses in ONE call and get one compact row each: launches, rug rate, the chain baseline, the multiple of that baseline, wallets tied, and the apparent-versus-true operator collapse. Use this instead of calling groundtruth_screen_creator in a loop. known_bad is true only when the creator is in the published set, has at least 5 resolved launches, and rugs at 1.5 times the chain baseline or worse -- a bare rug rate is noise, the multiple is a decision. known_bad is null, NEVER false, for a creator not in our count: not in our count means nothing either way.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Which chain these creators launched on. | solana |
| creators | Yes | Creator addresses. base58 for Solana, 0x... for Robinhood Chain. |
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.
Given one creator address, return every wallet that was early in that creator's launches: the role each played (creator, repeat_buyer, one_off), how many of this creator's launches it was early in versus how many it was early in anywhere, and the creator's own rug rate against the chain baseline, because a rate without its baseline is not a finding. It does not say who owns the wallets. LIVE FIELDS, from the mint feed every 5 s: last_mint_live (unix s of the dev's newest mint), launched_live, bonded_live and mints_since_asof; ticker_asof = the newest mint the feed has seen. A row with no mints_since_asof is not live: refuse it. bonded_asof dates the recount part; peak / pull and ttr_* are history (peak_proven / pull_proven false), not a trade signal; known_bad is the census rule.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Optional filter. Omit for all roles. | |
| chain | No | Which chain the creator launched on. | solana |
| limit | No | Maximum wallet rows to return. The response reports wallets_truncated when it caps. | |
| creator | Yes | Creator address. base58 for Solana, 0x... for Robinhood Chain. |
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.
Stamp a verdict ahead of the outcome, so it can be counted later. This is the honesty mechanism: the row is hash-chained to the previous one under your API key, so a verdict cannot be edited or removed after the coin resolves. Stamp every call you make, including the ones you are confident about -- a scorecard built only from remembered wins is not a scorecard. Returns the row hash and sequence number.
| Name | Required | Description | Default |
|---|---|---|---|
| ca | Yes | the coin address you are calling | |
| band | No | your own call, in your own scorecard; GROUNDTRUTH no longer publishes a band | |
| note | No | optional, up to 200 characters | |
| chain | No | ||
| rule_id | No | optional: your own rule label |
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.
WITHDRAWN 2026-09-29: the bands did not beat an age-matched baseline, so this now returns nulls plus band_withdrawn. Was: how fast coins in a given risk band actually rugged: median seconds from GROUNDTRUTH first seeing the curve to the rug, with p25 and p75, for one chain, band and window. Use it to answer "how long would I have had". The denominator is calls that rugged in the window AND carry a rug time, and it travels in the answer. Below 30 such calls the percentiles are null and enough_data is false -- say "not enough resolved calls to state a time" rather than quoting a number. Omit every argument to get the whole table in one call.
| Name | Required | Description | Default |
|---|---|---|---|
| band | No | withdrawn: GROUNDTRUTH no longer assigns a band; ignored | |
| chain | No | solana (pump.fun) or rh (Robinhood Chain) | |
| window | No | the resolution window; defaults to 24h |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, and the description adds substantial behavioral detail on top: the 2026-09-29 withdrawal, that it now emits nulls plus band_withdrawn, the enough_data flag, and the null-percentile threshold. This is exactly the extra 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?
The withdrawal notice is front-loaded, which is the most important fact, and the rest is dense but purposeful. It is a long single block with several clauses stacked together, slightly reducing scannability, but little is wasted.
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 shoulders return-value disclosure and does so for the key fields (nulls, band_withdrawn, enough_data). It does not enumerate the full response shape, but for a withdrawn tool this is nearly 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?
Schema coverage is 100% with all three enums documented, so the baseline is 3. The description adds real meaning beyond the schema by noting the band parameter is now ignored/withdrawn and that omitting every argument returns the whole table in one call.
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 statistic (median/p25/p75 seconds from first-seen curve to rug, per chain/band/window) and explicitly states its current withdrawal status and resulting behavior (returns nulls plus band_withdrawn). No sibling tool covers rug-timing percentiles, so an agent can distinguish it immediately.
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 a concrete use case ("how long would I have had"), the denominator definition, the 30-call threshold rule, and even the phrasing to use when data is thin. It stops short of telling the agent when NOT to bother calling a withdrawn tool or pointing to an alternative, which is the one gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One WALLET in, its counts out, from GROUNDTRUTH's own Solana capture tape (not a third party feed). Each of four fields is x/n with a one-line definition of n beside it, its rate, the same rate over all wallets, and the word above, below or about ("about" = within 2 percentage points): bad_share (buys in coins from creators with 5+ launches, 80%+ rugged, judged at each coin's launch; n = buys in coins whose dev we have counted), pre_rug_exits (n = the wallet's sells in coins that rugged; x = those in the 60 s up to the rug), copier_bagholder (buys where a wallet that first bought 1-2 s later still held at the rug; n = buys in coins that rugged where another wallet's first buy in that coin landed 1-2 s later; x = those where at least one wallet that first bought 1-2 s later had not sold at the rug) and early_buys (n = buys in coins with a known launch time; x = within 30 s of the launch). Then the tape range, buys_total (counts all buys; each n counts only the buys that meet its own condition), role (a label; role_label is its display form: deployer, early buyer or trader) and, for a deployer, its launches last (hand_label), dated, with the pip legend and what rugged means. A coin the wallet created itself is left out of the four fields (own_coins_excluded counts them). wallet_record is null, with wallet_record_reason, when the wallet is not in the tape cut (fewer than 100 buys in the tape range). Counts only. creator_record (a deployer) carries the LIVE FIELDS, from the mint feed every 5 s: last_mint_live (unix s of the dev's newest mint), launched_live, bonded_live and mints_since_asof; ticker_asof = the newest mint the feed has seen. A row with no mints_since_asof is not live: refuse it. bonded_asof dates the recount part; peak / pull and ttr_* are history (peak_proven / pull_proven false), not a trade signal; known_bad is the census rule.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | A Solana wallet address (base58). |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
groundtruth_kol_boardgroundtruth_kol_feedgroundtruth_copycheckgroundtruth_wallet_recordgroundtruth_seal_call2 fields changedInput schema / properties / band / descriptionPrevious value: -"the band you are calling it"New value: +"your own call, in your own scorecard; GROUNDTRUTH no longer publishes a band"Input schema / properties / rule_id / descriptionPrevious value: -"the rule_id behind the band, from the scan"New value: +"optional: your own rule label"groundtruth_time_to_rug1 field changedInput schema / properties / band / descriptionPrevious value: -"the band GROUNDTRUTH assigned at the time of the call"New value: +"withdrawn: GROUNDTRUTH no longer assigns a band; ignored"groundtruth_seal_call2 fields changedInput schema / properties / band / descriptionPrevious value: -"your own call, in your own scorecard; GROUNDTRUTH no longer publishes a band"New value: +"the band you are calling it"Input schema / properties / rule_id / descriptionPrevious value: -"optional: your own rule label"New value: +"the rule_id behind the band, from the scan"groundtruth_time_to_rug1 field changedInput schema / properties / band / descriptionPrevious value: -"withdrawn: GROUNDTRUTH no longer assigns a band; ignored"New value: +"the band GROUNDTRUTH assigned at the time of the call"groundtruth_seal_call2 fields changedInput schema / properties / band / descriptionPrevious value: -"the band you are calling it"New value: +"your own call, in your own scorecard; GROUNDTRUTH no longer publishes a band"Input schema / properties / rule_id / descriptionPrevious value: -"the rule_id behind the band, from the scan"New value: +"optional: your own rule label"groundtruth_time_to_rug1 field changedInput schema / properties / band / descriptionPrevious value: -"the band GROUNDTRUTH assigned at the time of the call"New value: +"withdrawn: GROUNDTRUTH no longer assigns a band; ignored"groundtruth_screen_creator2 fields changedInput schema / properties / role / descriptionPrevious value: -"Optional filter. Omit for all roles. operator_pool is the row that matters most."New value: +"Optional filter. Omit for all roles."Input schema / properties / role / enumPrevious value: -[
- "",
- "operator_pool",
- "repeat_buyer",
- "one_off"
-]New value: +[
+ "",
+ "repeat_buyer",
+ "one_off"
+]groundtruth_autopsy_indexgroundtruth_census_figuresgroundtruth_creator_flaggroundtruth_creator_replaygroundtruth_scan_coingroundtruth_scoreboardgroundtruth_scorecardgroundtruth_screen_batchgroundtruth_screen_creatorgroundtruth_seal_callgroundtruth_time_to_rugEvery pump.fun curve trade since 09-11: tape, launches, forensics, devs, odds + Meteora DLMM pools.
pump.fun & Robinhood Chain launch data: radar, risk checks, delta feed, datasets, keys. x402 USDC
Who is behind a launch: bundles, insiders, airdrops, serial devs. Solana pump.fun + 18 EVM chains.
Solana + pump.fun intel for agents: launch verdicts, token risk, dev/wallet records, smart money.
Add one secure layer between your agents and this server.
