Paxie.Matrix Data API

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

With no annotations, the description carries the full burden and does so: paper mode is simulated fills on live prices with no real money, random-twin baseline desks are excluded, data is rewritten every 60 s, calls cost $0.01 USDC via x402, and stale data yields a 503 with no charge. These are exactly the behavioral traits an agent needs before spending money.

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 and the sentence stays dense without filler, packing cost, staleness, and exclusion rules. It is long, but each clause (mode meaning, refund behavior, cost) earns its place; the enumeration of return fields is arguably redundant given the 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?

An output schema exists, so return values need not be explained, yet the description still enumerates them. Combined with the cost model, the 60 s rewrite cadence, the 503-on-stale refund rule, and the excluded baseline desks, an agent has everything needed to decide and call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for all three parameters, so the schema already documents book, limit, and since, making 3 the baseline. The description's parameter-relevant content is thin and slightly imprecise (it says book is 'main or explore' while the enum also includes 'all'); the 'mode' it mentions is a returned field, not an input, so it adds no input semantics.

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?

Names a specific resource (the Paxie.Matrix desk's closed trades on Solana and Robinhood Chain) with a clear scope (since a time, for track-record auditing) and lists the returned fields. It also distinguishes itself from the sibling aggregate endpoint at /v1/desk/stats, so an agent can separate it from the other desk-related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It routes the agent indirectly by noting that aggregates are free at /v1/desk/stats, implying this tool is for per-trade detail. It also states when the tool refuses (data older than 10 min → 503, not charged), which is practical selection context, but it does not explicitly say when not to use it versus the many sibling history/live 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?

With no annotations provided, the description carries the full behavioral burden and does so well: it discloses data freshness ('rewritten every 20 s'), a failure mode with financial consequence ('older than 120 s is refused with a 503 and not charged'), and the billing model ('Costs $0.03 USDC per call (x402)'). These are exactly the traits an agent cannot infer from the schema.

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-loads the headline ('Everything in one call') and then packs contents, freshness, and cost into three compact clauses with no filler. The dense enumeration is long but each item earns its place by telling the agent what it receives.

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?

An output schema exists, so return values need not be explained, and the description covers the remaining unknowns an agent needs: freshness window, staleness refusal behavior, and per-call cost. Nothing required to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single 'minutes' parameter is fully documented in the schema (range 1-240, default 60). The description's 'last 1-240 minutes' restates that range without adding syntax or semantics, 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 + resource ('Everything in one call') and enumerates exactly what the snapshot aggregates across both chains: live buyer bursts, pools opened in the last hour, and 24-hour tallies. This clearly distinguishes it from the many single-purpose siblings like rh_bursts_live, sol_bursts_live, and rh_pools_new.

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 phrase 'Everything in one call' implies this is the aggregate alternative to the per-chain burst/pool tools, but the description never explicitly says when to prefer it over the siblings or when not to. With 22 sibling tools, explicit routing guidance would materially help; here it is only implied.

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?

With no annotations the description carries the full burden, and it does so well: it discloses rewrite cadence (every 20 s), staleness (<= 30 s behind chain), failure behavior (stale data refused with 503 and not charged), and the billing model ($0.02 USDC per call via x402). Authentication specifics and any rate limits beyond payment are the only gaps.

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 dense sentences, front-loaded with purpose, costs, and freshness. Every sentence carries operational information (cost, staleness, label semantics); minor length is justified by the payment and freshness policies it must convey.

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?

Covers purpose, output meaning, freshness, failure mode, and cost — more than enough for a 3-param paid read tool that also has an output schema. The only meaningful omission is explicit routing to rh_bursts_live for real-time data.

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 enum values and defaults fully documented, so the baseline is 3. The description adds no parameter-level detail beyond what the schema provides, but it does usefully explain the outcome fields returned.

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 and scope: 'Scored Robinhood Chain buyer bursts from the last 1-24 hours', plus what each row contains. This distinguishes it from sol_bursts_history by chain, though it never names the live alternative rh_bursts_live, leaving the live/history split to be inferred from the name.

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?

No explicit when-to-use or when-not guidance and no mention of the sibling rh_bursts_live for current data. The freshness rule ('data older than 120 s is refused with a 503') implies the tool is for recent-but-not-instant history, but the agent must infer that routing itself.

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?

With no annotations, the description carries the full burden and does so richly: rewrite cadence (every 20s), staleness limit (<=120s then 503, not charged), per-call cost ($0.01 USDC via x402), the fields each burst carries, and that outcomes are scored 30 minutes post-signal. An agent knows the freshness, cost and failure semantics before calling.

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 nearly every clause carries operational value (fields returned, scoring, freshness, cost, refusal behavior). The first sentence is clause-dense and slightly run-on, so it reads crowded rather than 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?

Given an output schema exists, return formatting needn't be explained, and the description still covers scope, returned signals, scoring lag, freshness, staleness refusal and pricing. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with two enums fully documented (lp, tier), so the schema does the heavy lifting. The description adds only marginal meaning, restating the 1-240 minute range and the rug-check concept ('who held the pool's liquidity at the signal') that the lp field already encodes.

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 ('buyer bursts'), the chain (Robinhood Chain), the source universe (every ETH-quoted Uniswap v4/v3 pool created in the last 24h) and the time window (1-240 minutes). The 'live' framing and freshness guarantees distinguish it from the history sibling without 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?

Clear context for when this applies: real-time signal monitoring with a hard <=30s freshness window and a 503 refusal past 120s, which implicitly routes backtesting/older lookups elsewhere. It never names an alternative sibling (e.g. rh_bursts_history) or states an explicit when-not, so it stops short of a 5.

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

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

With no annotations present, the description carries the full burden and does so: 20s rewrite cadence, <=30s chain lag, a 120s staleness cutoff that returns 503 without charging, and a $0.02 USDC x402 payment requirement. These are exactly the operational facts an agent needs before calling, and none are available in 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?

Four sentences, front-loaded with the definition and then the practical constraints; nothing is padding. The 'spot sniper crews before they dump' sentence duplicates ground covered by the usage framing, which is the only mild redundancy.

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?

An output schema exists, so return values need not be described, and the remaining agent-relevant facts — freshness guarantees, failure mode, and cost — are all stated. For a two-parameter read endpoint with a payment gate, nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so limit and minBursts are already fully documented with ranges and defaults. The description's 'bought inside 3 or more of the buyer bursts' loosely echoes minBursts' default but adds no syntax, unit, or interaction detail beyond the schema, 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?

Names a specific resource (repeat-buyer clusters on Robinhood Chain) and defines the selection rule precisely: wallets that bought in 3+ captured buyer bursts, with burst count and last-seen time. This resolves the opaque name 'rh_crews' and distinguishes it from siblings like rh_bursts_live and rh_bursts_history, which report bursts rather than clustered wallets.

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 intended use ('spot sniper crews before they dump on you'), which implies the detection scenario, but never contrasts this with rh_bursts_live / rh_bursts_history or states when this tool should be preferred over fetching raw burst data. Usage is implied rather than routed.

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?

With no annotations, the description carries the full burden and does it well: 404 for untracked pools (not charged), 20 s rewrite cadence with up-to-30 s lag, 503 refusal for data older than 120 s (not charged), and a stated price of $0.005 USDC via x402. These are exactly the failure modes, staleness and cost facts an agent needs before calling.

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 and return shape are front-loaded, then error/cost behavior. Dense and information-rich, with every clause (404, staleness, pricing) earning its place, though the single long parenthetical-of-clauses could be split for 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?

An output schema exists so return values needn't be detailed, yet the description still summarizes them; combined with dependency source, error semantics, freshness guarantees and per-call pricing, an agent has everything required to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema already documents the id as a v4 bytes32 hex or v3 address from rh_pools_new, so the description mostly repeats it. It does add that id is a path parameter, but adds no format examples or validation detail beyond the schema; 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+resource: fetch one Robinhood Chain Uniswap pool's flow by v4 pool id or v3 address. The scope (single pool, 1-minute buckets over the last 60 minutes plus burst history) clearly separates it from list-style siblings like rh_pools_new and the rh_bursts_* tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names the upstream source for the id (/v1/rh/pools/new, i.e., rh_pools_new), which is genuine usage guidance. However it never says when to prefer this tool over rh_bursts_live or rh_bursts_history, despite overlapping on burst data, and gives no explicit exclusions.

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?

With zero annotations, the description carries the full burden and does so: 20s rewrite cadence, data <=30s behind chain, hard refusal (503, unbilled) past 120s staleness, and $0.005 USDC per call via x402. Cost, freshness and failure behavior are all disclosed — exactly the context annotations would normally supply.

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 what is returned, then freshness/staleness, then cost — every sentence earns its place. The long first sentence enumerates output fields that the output schema already covers, which is slightly redundant but useful for a selection decision.

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?

An output schema exists, so return-value detail is not required of the description, and the remaining agent-critical facts (freshness SLA, 503 behavior, per-call price, payment rail) are all present. Nothing needed to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (hours, limit) are already fully documented with ranges and defaults; baseline is 3. The description adds only marginal value by grounding the 'hours' window as 1-24 in prose and never mentions 'limit'.

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 (ETH-quoted Uniswap v4/v3 pools opened on Robinhood Chain), a precise scope (last 1-24 hours, youngest first), and the exact payload fields returned. The age-window scope inherently separates it from siblings like rh_pool_flow and rh_bursts_history without needing to name them.

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 rather than stated: fresh-pool discovery within a 1-24h window, with burst tiers cross-referencing the rh_bursts_* family. There is no explicit when-to-use/when-not or named alternative, so an agent must infer the call context.

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?

With no annotations, the description carries the full behavioral burden and does so thoroughly: cost ($0.02 USDC via x402), 404-not-charged for tokens with no call, 503-not-charged for stale data, 30s rewrite cadence, 180s freshness limit, and an explicit privacy note that no chat names/callers/message text are returned. This is exactly the operational context an agent needs before calling.

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, but delivered as one very long colon-and-semicolon run-on that crams definitions, error codes, pricing, and disclaimers into a single sentence. The content is dense and largely earns its place, yet the lack of any structural break makes it harder to scan 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?

Behaviorally complete: freshness, pricing, error semantics, and privacy are all covered, and the output schema handles return structure. Some return-field definitions (run60, flags thresholds) are restated in the description despite the output schema, which is slight redundancy but not a gap. Nearly everything an agent needs to call this correctly is present.

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 'addr' parameter, which already documents the 0x+40-hex format, so the schema does the heavy lifting. The description adds no syntax or format detail for the argument beyond restating 'on-chain addresses'. 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 names a specific dataset and scope: pre-call token activity over the hour before a Telegram call, covering every call seen in the last 48h, with named output fields (run60, flags, pre-post buyer wallets). It is easy to tell apart from rh_token_verdict or rh_token_rugcheck by content, though it never explicitly names those siblings. Clear and specific, but no direct 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?

Usage is strongly implied by the content ('what a token did in the hour before a call'), and the 48h window and flag definitions give context for when the result is meaningful. But there is no explicit when-to-use/when-not, no named alternative for pre-call vs post-call analysis, and no stated prerequisite beyond the address. Implied usage only.

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?

With no annotations, the description carries the full burden and does so well: it discloses the per-row re-profiling cadence for pools under 6 hours old, checkedAt semantics, the class taxonomy (held/safe/unknown/empty), the 404-and-not-charged behavior for untracked tokens, and a concrete price of $0.02 USDC via x402. That covers payment, error, and freshness behavior an agent needs before invoking a paid call.

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 in the first clause, then edges (pools, curves, 404, price) follow in a logical order. It is on the long side and the price/payment sentence could sit nearer the top, but essentially every sentence conveys distinct operational information.

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 one-parameter paid read tool with an output schema, this is complete: cost, payment mechanism, error behavior, refresh cadence, and the two distinct response shapes (LP pools vs pons-curve) are all covered. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single addr parameter, so the 3 baseline already applies. The description adds marginally useful framing that the schema lacks: addr is a path parameter and specifically a token contract address, which helps the agent place it correctly in the 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?

States a specific verb and resource (rug check for a Robinhood Chain token) and scopes the output precisely: LP ownership profile of each tracked Uniswap v4 pool, plus pons-curve bonding-curve data. An agent can tell it apart from close siblings like rh_token_precall and rh_token_verdict by the LP/insider-share framing, though it never names an alternative 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?

"Before you buy" gives clear context for when this should be called, and the pons-curve note tells the agent what to expect in that specific situation. There are no explicit exclusions or named alternatives (e.g., when to prefer rh_token_verdict), so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and does so richly: 404 for untracked tokens (not charged), 20s/30s refresh cadences with stale inputs refused via 503 (not charged), $0.03 USDC x402 cost, and a research-data disclaimer. These are exactly the operational traits an agent needs and that no schema field encodes.

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 outcome ('avoid, caution or ok') before the supporting machinery, and every clause carries a distinct fact (inputs, errors, freshness, cost, disclaimer). It is dense and long, but nothing is padding.

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?

An output schema exists, so return values need not be explained, and the description covers what remains: the decision inputs, not-charged error paths, staleness handling, pricing, and the non-advice disclaimer. An agent has everything needed to call it correctly and interpret failure modes.

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% for the single addr parameter and its description already specifies the 0x+40-hex format, so the schema does the heavy lifting. The description adds only the implicit context that the address is a Robinhood Chain token, which triggers the verdict lookup, so 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 ('verdict' on a 'Robinhood Chain token') and the exact deliverable ('avoid, caution or ok, with every reason'). It names the concrete inputs it aggregates and is clearly distinguishable from sibling rh_token_rugcheck and rh_token_precall, which it consumes rather than duplicates.

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?

'One call before you buy a Robinhood Chain token' gives clear decision-point context, and the composition (rug check + pre-call + desk outcome) implicitly routes agents here instead of the component tools. It stops short of an explicit 'use this instead of rh_token_rugcheck' exclusion, so not quite a 5.

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

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

With no annotations, the description carries the full burden and does disclose the two traits that matter most: a 15-minute data-freshness lag and a hard result cap (3 bursts per chain, 3 pools). It does not state auth requirements or how the cap interacts with paging, but the staleness and volume limits are genuine behavioral disclosure.

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 dense sentence, front-loaded with the defining constraint (delayed preview) and free of filler. Every clause conveys a distinct fact: delay, scope, quota, and cost.

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?

An output schema exists, so return structure need not be explained, and the description covers cost, latency, and volume limits. What is left unstated is which chains 'per chain' actually covers, a small ambiguity given the many chain-specific siblings.

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; there is nothing for the description to disambiguate beyond confirming no inputs are needed.

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 resource set: a 15-minute-delayed preview containing 3 bursts per chain plus 3 young Robinhood pools. An agent can tell this is a read-only sample/preview endpoint rather than a live feed, though it never explicitly names the sibling tools (rh_bursts_live, rh_pools_new) it mirrors in delayed form.

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?

'Free' and 'No payment' imply this is the no-cost alternative to a paid feed and is meant for a quick look rather than full analysis, but no when-to-use condition, prerequisite, or named alternative is given. Usage is left to inference from the word 'preview'.

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?

With no annotations present, the description carries the full burden and does so: $0.01 USDC per call via x402, written every 30 s, refused with 503 if data is older than 180 s, 404 for unscanned mints, nothing charged on failure, derived fields only and no reproduction of the source cards, and an explicit research-not-advice disclaimer. This is a richer operational profile than most annotation sets provide.

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 in the first clause, and the trailing sentences each carry operatively useful facts (payment model, 48 h window, 30 s/180 s freshness rules, fee-on-failure, disclaimer). It is dense rather than padded, though the phrasing is compressed enough that a reader must work to unpack where behavior ends and disclaimers begin.

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?

An output schema exists, so return values need no prose. Combined with the coverage window, freshness SLAs, payment terms, error semantics, and scope caveats, an agent has everything needed to decide whether to call this tool and to interpret failures correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single `mint` parameter, so the schema already documents type and intent. The description adds only the informal restatement that the token can be a Solana mint or a Robinhood Chain token, matching rather than extending the schema. Baseline 3 applies when the schema does the heavy lifting.

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 (grade A-F) and resource (Solana or Robinhood Chain token) and enumerates the exact inputs that drive the grade: holders, top-10 share, largest holder, snipers, bundles, dev holding, fresh wallets, curve progress. It is clearly a distinct artifact-analysis tool, but it never names a sibling, leaving ambiguity against sol_token_verdict, rh_token_verdict, and rh_token_rugcheck.

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 concrete inclusion criteria (tokens the desk scanned in the last 48 h), explicit failure behavior for out-of-scope calls (404, not charged) and for stale data (503, not charged), plus cost. There are no exclusions or alternatives named, so an agent still has to infer whether a verdict tool would be better for the same mint.

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?

With no annotations, the description carries the full burden and does so well: it discloses the 20 s rewrite cadence, the 120 s staleness cutoff with a 503 refusal, that refused calls are not charged, and the $0.02 USDC x402 cost. This is exactly the operational context an agent needs and cannot get from the schema.

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 dense sentences, zero filler, and the most decision-relevant facts (what it returns, freshness, cost) are front-loaded. Every clause 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?

An output schema exists, so return formatting is covered elsewhere, and the description supplies the remaining operational essentials: freshness cadence, staleness failure behavior, billing, and cost. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single 'hours' parameter is fully documented in the schema (1-24, default 24). The description reinforces the 1-24 hour range 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 states a specific resource (scored Solana pump.fun bonding-curve bursts) and enumerates exactly what is returned: graduation, speed, peak return, and per-exit-rule returns. It implies the historical/live distinction via 'last 1-24 hours' but never explicitly names sol_bursts_live as the real-time alternative, so it stops short of full 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?

The 'last 1-24 hours' window and the historical framing imply a retrospective-analysis use case, but there is no explicit when-to-use/when-not-to-use guidance and no named alternative. The agent must infer that sol_bursts_live is the real-time counterpart.

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?

With no annotations, the description carries the full behavioral burden and does so well: it discloses the 20-second rewrite cadence, the 120-second staleness cutoff, the resulting 503 failure mode with a no-charge guarantee, and the $0.01 USDC x402 price. These are exactly the operational facts an agent needs before calling.

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 signal and window, then layered with burst contents, scoring, freshness, and pricing. Dense but every clause carries operational meaning; it runs long, 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?

An output schema exists, so return shape needn't be explained, and the description covers scope, filters, sampled-vs-unsampled burst detail, scoring horizon, freshness guarantees, failure behavior, and cost. Nothing essential to a correct call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single 'minutes' parameter, including its 1-240 bounds and 60 default, so the schema does the work. The description repeats the range ('last 1-240 minutes') but adds no semantics beyond it, making the baseline 3 correct.

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 and scope: 'Solana pump.fun bonding-curve buyer bursts from the last 1-240 minutes,' which pins down chain, venue, signal type, and window. The recency framing implicitly separates it from sol_bursts_history, but the sibling is never named, so an agent must infer the split.

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 token-age and curve-progress filters ('5 min to 4 h old that show curve progress') imply when the tool is applicable, but there is no explicit when-to-use or when-not-to-use guidance and no routing to sol_bursts_history or rh_bursts_live. Usage is inferable rather than stated.

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?

With no annotations, the description carries the full burden and does so richly: caller anonymity via sha1 hashes, chat names exposed only for public channels/groups, hourly rebuild cadence, 503 refusal (uncharged) when data is older than 3h, and a $0.05 USDC x402 charge per call. These are exactly the operational facts an agent needs before invoking.

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 identity ('Telegram call-channel callers ... ranked by ...'), followed by metric definitions, privacy rules, windows, and cost. Dense and single-paragraph, but each clause contributes operational information; only the lengthy metric enumeration risks being a run-on.

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?

An output schema exists, so return shape needn't be explained. For a paid, periodically rebuilt data tool the description covers pricing, staleness/refusal behavior, anonymization, and scoring windows — nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so baseline is 3, but the description goes further by defining the metrics that the sort enum values refer to (e.g., win35 = '+35% before -20%', hit15 = '+15% within 60 min', rug = '-80% within 60 min'). This gives the enum options meaning the schema alone does not convey.

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 precise verb+resource: 'Telegram call-channel callers ... ranked by what happened after their own posts', with the exact metric set (hit15, win35, x2, rug rate, median returns). This is clearly distinguishable from siblings like sol_calls_live, sol_calls_outcomes, and sol_wallet_leaders.

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 names the available windows and the ranking basis, implying when the tool is useful, but never says when to prefer it over sol_calls_live, sol_calls_outcomes, or the wallet leaderboard tools. No exclusions or alternative-selection guidance is 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?

With no annotations, the description carries the full burden and does so well: it discloses a 20 s rewrite cadence, a 503 refusal (not charged) when data exceeds 120 s, a $0.02 USDC x402 cost per call, and the privacy rule that public channels are named by @username while private chats appear only as counts. It stops short of explaining auth/payment setup or any result-count cap, so it is strong but not exhaustive.

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 resource and bounded window, and there is no filler or hedging across its four sentences. The long enumerated list of returned fields is partly redundant given an output schema exists, which slightly dilutes conciseness, but the density is otherwise justified.

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-param, read-only live-feed tool with an output schema, the description covers freshness, refusal behavior, cost, and channel-anonymization semantics – the operational facts an agent actually needs. The main remaining gap is guidance on how it relates to sibling feeds, which leaves selection to inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (chain, minutes) are already documented with defaults, enums and bounds; the baseline is 3. The description restates the 1-120 minute window and both chains but adds no syntax, format, or interaction 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?

States a specific resource precisely: contract addresses surfaced by followed Telegram call chats within a bounded look-back window, along with the derived fields returned. An agent can distinguish it from historical siblings like sol_calls_outcomes or bursts tools by the 'last 1-120 minutes' framing, but the description never names a sibling, so routing relies on inference.

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 1-120 minute live window and the 'followed Telegram call chats' scope, which tells an agent roughly when this is the right feed. However, there is no explicit when-to-use versus alternatives (e.g. sol_calls_outcomes for settled results, sol_bursts_live for volume spikes) and no stated preconditions such as requiring followed chats to exist.

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?

With no annotations, the description carries the full burden and does so well: sampling cadence (every 10 min), provenance (own series, no third-party prices), privacy handling (callers hashed, chats named only if public), cache freshness (rebuilt hourly, 503 and not charged if >3h stale), and cost ($0.05 USDC via x402). Missing details are secondary — how payment/auth is actually performed and pagination behavior.

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 payload is front-loaded: the dataset contents lead, and operational facts (provenance, freshness, cost) follow. It is dense and slightly run-on, but nearly every clause carries information an agent needs, and it is appropriately sized for the amount of behavior being disclosed.

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?

An output schema exists, so return structure is covered elsewhere, and the description supplies the provenance, freshness, and cost context that structured fields cannot. An agent has enough to decide and call it, though the lack of any alternative-routing note is the one real 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 description coverage is 100% and all three parameters are self-documented with types, ranges, and defaults. The prose only echoes the 1-48 hour window and the Solana/Robinhood scope, adding no format or syntax detail beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a precise resource: historical human calls from followed Telegram chats (Solana/Robinhood) with returns at 1/4/12/24/48h, the 48h high, the pre-high dip, and death status. That is far more specific than a restated name and lets an agent infer it is the outcome/history counterpart to sol_calls_live. It stops short of explicitly naming that sibling, so it is clear but not sibling-routing.

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 when-to-use guidance and no mention of alternatives such as sol_calls_live, despite 20+ siblings. The 1-48 hour age window and hourly rebuild imply the data scope, but the agent gets no explicit instruction on when this tool is the right choice versus the live feed or the leaderboard.

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?

With no annotations, the description carries the full burden and delivers: data is rewritten every 20s, requests are refused with 503 (and not charged) if data is older than 120s, and each call costs $0.02 USDC via x402. Freshness, error semantics, and payment/auth context are all disclosed.

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 purpose, then behavior, then cost, in three tight sentences with no filler. Every clause adds information an agent needs.

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?

An output schema exists, so return-value detail is correctly omitted, and the freshness/cost caveats make this self-sufficient for calling. The only gap is that the description never situates this relative to the live sibling, which matters for a history/live pair.

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 both params, so the schema already documents 'hours' and 'limit' with ranges and defaults. The description restates the 1-48h window but adds no format or interpretation detail beyond the schema, 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 a specific resource (Solana pump.fun graduations) plus the exact aggregate payload: median time on curve, buyer-burst counts, and post-graduation returns at 1/5/15 minutes. The 'history' scope and 1-48h window make it distinguishable from the live sibling at a glance.

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?

Implied usage is clear (retrieve historical graduation aggregates over a look-back window), and the freshness note helps the agent know when the data is usable. However, it never states when to prefer this over sol_grads_live or any other sibling, nor any exclusions.

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?

With no annotations, the description carries the full burden and does so well: it discloses the 20 s rewrite cadence, the 120 s staleness limit with a 503 refusal that is not charged, and the $0.01 USDC x402 payment requirement. These are exactly the operational traits an agent needs before calling.

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 resource and scope are front-loaded, and each subsequent sentence covers a distinct concern (returned fields, freshness, cost). It is dense with domain jargon but the clauses earn their place; the field enumeration is the only mildly redundant part given an output schema exists.

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 single-parameter, output-schema-backed tool, the description covers scope, freshness, failure behavior, and cost. The field-by-field return description is redundant against the available output schema, and no result-size or pagination limits are mentioned, leaving 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?

Schema description coverage is 100% and the single parameter is fully documented in the schema, so the baseline is 3. The description restates the 1-240 range without adding format or default semantics beyond what the schema already 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 names a specific resource (Solana pump.fun graduations) and a precise scope (last 1-240 minutes), and the freshness/rewrite language conveys the 'live' character. However, it never names sol_grads_history, the obvious sibling, so the live-vs-history routing must be inferred 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?

Usage is implied through the look-back window and freshness semantics (data rewritten every 20 s, refused if stale), which tells an agent this is for near-real-time reads. There is no explicit when-to-use vs sol_grads_history or the rh_* burst tools, and no stated exclusions.

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?

With no annotations, the description carries the full burden and does so: data rewritten every 30 s, 503 refusal if older than 180 s, 404 for unseen mints, no charge on failed calls, and $0.02 USDC x402 pricing. It also disclaims research-only status. These are exactly the operational facts an agent needs.

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?

Long but front-loaded: the return contents lead, then freshness/error semantics, then pricing. Almost every clause adds operational value, though the single dense paragraph runs on and the return enumeration could be tightened given an output schema exists.

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?

An output schema exists so return values need not be explained, yet the description still orients the agent on what is and isn't included. Combined with freshness, error, and billing semantics, nothing needed to invoke this confidently is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one required parameter (mint) and schema description coverage is 100%, so the schema already documents it fully. The description adds no format, constraint, or example beyond what the schema provides, 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?

States a specific resource (a Solana mint's recorded desk data over the last 48 h) and enumerates exactly what is returned: safety gate, scout scores, scanner-card grade, trader action, shadow outcomes, last closed paper trade. An agent can distinguish this from siblings like rh_token_verdict or sol_callers_leaderboard without opening a 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?

Clearly frames the trigger condition (want everything the desk recorded on a given mint) and the negatives (no thesis, no bot card, no chat content), which tells the agent when this is the wrong tool for narrative/chat data. It does not explicitly name an alternative sibling for cases the exclusions cover, so it stops short of full routing 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?

With no annotations, the description carries the behavioral burden and does so well: it discloses the $0.01 USDC x402 cost, hourly rebuild cadence, and that untracked wallets return 404 and are not charged. It does not cover auth requirements or rate limits, keeping it short of 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 purpose is front-loaded and the trailing operational sentences (addresses, rebuild, 404, cost) are each load-bearing. The central field enumeration is dense and long, but it is informative rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't explain return values, yet it adds the operational essentials an agent needs: cost, freshness, and untracked-wallet behavior. Nothing required to call this paid endpoint correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both addr and limit. The description's '(newest 100)' loosely echoes the limit default but adds no syntax, format, or constraint 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 description names a specific resource (every buy by one Solana copy-leader wallet over the last 14 days) and enumerates the exact return content, so an agent knows precisely what it gets. The verb is implicit in the enumeration rather than an explicit 'retrieve stats', and it never names the sibling sol_wallet_leaders it pairs with, which keeps it from a full 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?

Usage context is only implied: the schema tells the agent where addr comes from (sol_wallet_leaders) and the description notes untracked wallets return 404, which helps a caller decide. But there is no explicit when-to-use-vs-alternatives statement and no comparison against sol_wallet_leaders or the leaderboard 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?

With no annotations, the description carries full behavioral burden and does so richly: it discloses the ranking methodology (replay of 60 buys through a fixed exit, shrinkage toward pooled mean), refresh cadence (rebuilt hourly), failure behavior (503 and not charged if older than 3h), and cost ($0.05 USDC via x402). These are exactly the operational traits an agent needs before calling a paid, snapshot-based tool.

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 identity before methodology, cost, and staleness details. The methodology sentence is dense but every clause (exit rules, shrinkage, fees, cap) explains the ranking and thus earns its place; nothing is 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?

For a paid snapshot leaderboard with an output schema present, the description covers the remaining gaps: what gets returned conceptually (sample size, win share, sell pattern), data freshness, failure semantics, and pricing. An agent has everything needed to decide whether and how to call 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?

There is a single optional parameter whose schema description coverage is 100% ('Max rows, 1-50 (default 50)'), so the schema already documents it fully. The description adds nothing about the limit parameter, making the baseline score of 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?

The description names a specific resource and ranking metric: 'Top Solana copy-trade leaders ranked by shrunk replay EV,' with a clear explanation of the ranking construction. It is easy to distinguish from generic leaderboards, though it never explicitly contrasts itself with closely named siblings like sol_wallet_copy_stats or sol_callers_leaderboard, which an agent must infer.

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 implied (find wallets worth copy-trading) but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as sol_wallet_copy_stats for a single wallet. The staleness rule ('refused at 503 if older than 3h') is a precondition, not usage 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?

No annotations are provided, so the description carries the full disclosure burden. It does add one piece of non-schema information — that the call is free — plus a hint at the returned subject matter (freshness, payment networks, price list). It stops short of stating side effects, auth requirements, or whether output is cached/live, but with an output schema present the return-shape burden is lifted.

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 short sentence with no padding and the cost signal front-loaded. It is efficient, though the terseness tips into under-specification rather than disciplined brevity.

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 tool with an output schema, the description needs only to establish purpose and any cost/auth caveats; the output schema covers return values. It conveys the free-call fact but leaves the tool's actual purpose ambiguous relative to a large, dense sibling set.

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 input schema has zero parameters, so per the rubric the baseline is 4. There are no arguments whose semantics need explaining, and the description introduces none.

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 three data categories (data freshness, payment networks, price list) but supplies no verb and no clear statement of what the tool actually returns or does — it reads as a fragmentary restatement of the name 'status'. Against siblings like sol_token_verdict or rh_pool_flow, an agent gains little ability to distinguish this tool's role.

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 'Free:' prefix hints this is a zero-cost call, which is a mild usage cue, but there is no explicit when-to-call guidance, no prerequisites, and no mention of alternatives. An agent cannot infer from the text whether this is a health-check/preflight tool or a data retrieval endpoint.

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?

With no annotations, the description carries the full burden and delivers: fixed $0.50 USDC per pass via x402 regardless of duration, 60-minute ceiling, heartbeat cadence, event-append cadence, a 2-connection limit, auth via URL token, and the fact that a 503 stream_disabled response is not charged. That is unusually rich disclosure of cost, limits and failure semantics.

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-loads price and duration, then event types, then operational details — a sensible order with no filler sentences. It is one very dense sentence, so a comma-separated clause list would parse more cleanly, but nothing 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?

An output schema exists, so return shape need not be explained, and the description covers pricing, cadence, limits and error behavior for a streaming tool. The remaining gap is routing: it does not say how this streaming pass relates to the live/history polling siblings, which is the main missing decision input.

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 there is only one parameter, so the baseline is 3. The description adds meaningful semantics beyond the schema by clarifying the pass is billed per pass and not per call, meaning the choice of minutes does not change cost — useful decision context the schema does not convey.

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 resource and delivery mode: a paid SSE stream at /v1/sol/bursts/stream pushing pump.fun/Robinhood Chain buyer bursts, graduations and Telegram calls. It is clear what the tool does, but it never names or contrasts the polling siblings (sol_bursts_live, rh_bursts_live, sol_calls_live) that overlap heavily with this event set, so sibling differentiation is left to inference.

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 rather than stated: the 'per pass, not per call' framing hints at a choice between streaming and per-call endpoints, and details like the 2-connection cap and 503 behavior give practical context. However, there is no explicit when-to-use/when-not guidance and no named alternative for agents that only need a one-shot snapshot.

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