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

Annotations declare the safety profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true), and the description goes well beyond them: it discloses billing trigger ('charged when at least one mint is covered and feed lag <= 5 s'), refusal conditions before payment, per-mint coverage behavior, and a 'no flags observed is not a safety guarantee' caveat. This is unusually rich 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?

Front-loaded with price and use case, and nearly every clause carries operational information. It is dense and slightly packed into long sentences, 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 still explains the return shape ('compact check's item plus its verdict word and market') and the partial-coverage case (unavailable listing). Nothing an agent needs to call and interpret the batch 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 description restates the essentials (1-25 distinct, mint or pump.fun/gmgn/solscan/birdeye link). It adds meaning beyond the schema by explaining what happens to a mint outside the live window and that malformed or repeated mints cause refusal, though it does not expand on link parsing syntax.

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 1-25 mints) plus the pricing unit up front. It explicitly contrasts with check_watchlist_risk, so an agent can distinguish it from a close sibling without opening the 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 a concrete trigger ('use when a screener checks a list, some possibly outside the live window') and a cost crossover rule naming the alternative ('from 21 mints up it costs less per mint than check_watchlist_risk'). When-to-use and when-to-prefer-the-alternative are both explicit.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine operational context beyond that: the free tier, a <=5s feed-freshness guarantee, and the fact that the response contains availability plus exact prices rather than risk findings. It stops short of rate limits or failure modes, 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?

Three short sentences, front-loaded with the 'Free.' differentiator and the coverage claim, then the usage rule. Every clause carries decision-relevant information with 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?

With no output schema, the description compensates by stating what is returned (availability and exact prices) and what is not (risk findings), and it scopes inputs to 1-5 mints. For a one-parameter read-only tool, an agent has everything needed to call it correctly and interpret the result.

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 'mints' parameter is fully documented in the schema (type, minItems/maxItems, accepted link formats). The description only echoes the 'one to five' cardinality, adding no new syntax or format detail, 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 ('check full live coverage ... for one to five pump.fun mints'), names the scope limit, and explicitly distinguishes itself from the paid siblings by noting it 'returns no risk findings' and is free. An agent can select it over check_pumpfun_risk/check_batch_risk without opening any 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 explicit when-to-use ('right before a paid check') and an explicit when-not/no-value case ('it returns no risk findings'), which is exactly the routing information an agent needs in a 29-tool namespace. Nothing is left to inference.

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

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

Goes well beyond the annotations: discloses the $0.005 price, the refusal conditions (uncovered, stale, or curve not quoted in SOL => refused before payment, nothing charged), and cursor semantics (no new watched events => unpaid). Annotations only say non-readOnly/openWorld; the description supplies the real operational envelope.

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 the core use case, then inputs, returns, and failure modes. Dense and parenthetical-heavy but nearly every clause carries operational information; only mild redundancy with the schema keeps it from a 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 still enumerates the return surface (flags_observed/no_flags_observed, timestamped findings, holder concentration, buyer flow, market, authorities, P(rug within 5 min), P(true graduation)) plus cost and refusal behavior. Nothing essential for correct invocation 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 params are already documented, including that mint accepts a pump.fun/gmgn/solscan/birdeye link and that cursor is an opaque watch cursor. The description restates the cursor's unpaid-on-no-new-events behavior rather than adding meaning 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 verb+resource+scope: a pre-trade rug check on ONE pump.fun mint, right before a swap or while holding. It also names the sibling tools used for finding new mints (radar, launches_since), so an agent can separate this from discovery 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?

Gives clear timing context ('right before a swap or while holding ONE pump.fun mint') and points at radar/launches_since for mint discovery. It does not explicitly distinguish this from near-neighbors like check_watchlist_risk or token_safety, so it stops short of full alternative routing.

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

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

Adds substantial context beyond the annotations: per-call pricing model, the refusal precondition (full live coverage and feed lag <= 5 s, refused before payment), the retry/replay window for an identical signed payment, and an explicit 'no flags observed is not a safety guarantee' caveat. These are exactly the operational traits an agent needs and none are derivable from readOnlyHint/openWorldHint.

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?

Information-dense and front-loaded, with pricing and the usage rule leading. Nearly every clause earns its place, though the single run-on paragraph packs pricing, input format, output contents, preconditions and retry policy together, which makes it harder to scan than a short structured list would be.

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 return-value burden itself and does so: it enumerates the per-mint payload (findings with first-observed times, P(rug within 5 min), P(true graduation), concentration, flow, market and authorities). Combined with the payment and refusal rules, 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 the baseline is 3, and the description goes further by restating accepted input forms (raw mint or pump.fun/gmgn/solscan/birdeye link) and by explaining cursor semantics that the schema only calls 'opaque' — namely that a cursor with no new watched events returns an unpaid result.

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+scope: a batch rug check for one to five pump.fun mints at a flat $0.01, and explicitly names the sibling it is not (check_pumpfun_risk for a single mint). An agent can distinguish it from check_batch_risk, token_safety and mint_risk_card without opening any 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 selection rule ('use when you hold or watch two to five pump.fun mints'), names the cheaper single-mint alternative with its price, and points to the free alternatives (check_coverage, watchlist_updates). Both when-to-use and when-to-use-something-else are covered.

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?

Adds real context beyond the annotations: per-call cost ($0.02), that a stale feed is refused before payment, that only outcomes known at request time count, and that an unseen wallet returns is_first_time=true. The readOnlyHint=false is consistent with a paid call rather than contradicted by any claim of a write. It does not cover pagination/format detail, but the paid-and-refusable behavior is the important 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?

Cost and purpose are front-loaded, and nearly every clause carries distinct information (graduation threshold, rug definition, warm-launch funding window). The middle sentence is a long run-on list, which costs some readability but wastes little.

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 takes on the return-shape burden and does so: it enumerates the counters, the last-25-launch detail, live mints, and is_first_time. An agent knows what it will get, what it costs, and when the answer is refused.

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 address parameter is fully documented (base58, 32-44 chars). The description restates "address (base58 wallet)" but adds no syntax or format beyond the schema, so the baseline 3 applies. The is_first_time=true note is output semantics rather than parameter meaning.

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

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

States a specific verb and resource: judging a new pump.fun token by its creator's prior launch history, and enumerates the exact signals it returns (n_launches, graduations, rugs, time-to-first-sell). It also explicitly differentiates from siblings by pointing at check_pumpfun_risk and mint_risk_card for the launch itself.

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?

"Use to judge a new pump.fun token by its creator's earlier launches" gives the positive trigger, and "For the launch itself use check_pumpfun_risk or mint_risk_card" names the alternatives for the adjacent case. When-to-use and when-to-use-something-else are both explicit.

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

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

Annotations only declare readOnly=false, openWorld=true, idempotent=false, destructive=false. The description adds substantial context the annotations cannot carry: the $0.01 cost, the refusal-before-payment behavior on stale or empty feeds, the <=5 s feed-lag requirement, the ~30 s response time, the fixed rule source (/v1/labels), and the explicit disclaimer that no_flags_observed is not a safety guarantee.

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?

Nearly all content earns its place, but it is delivered as one ~110-word run-on sentence followed by fragments, which hurts front-loading and scanability. Pricing leads, which is reasonable, but the return-shape and refusal details are buried mid-sentence.

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

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

With no output schema, the description carries the burden of describing the return payload (verdict word, reason(s), P(true graduation), P(rug within 5 min), age, curve SOL, buys, market, authorities, links, scanned/avoid_skipped counts) and the refusal semantics. That is thorough, though the extreme compression leaves some mapping ambiguities.

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

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

Schema coverage is 100%, so both limit (1-50) and max_age_s (30-3600) are already documented. The description corroborates but does not extend them - 'default last 15 min' and 'up to 50' simply restate the schema defaults and cap, 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 names a specific verb+resource: newest screened pump.fun launches filtered to verdicts that are not 'avoid', ranked by P(true graduation), capped at 50. It is narrow enough to distinguish itself from sibling listing tools like launches_since or recent_launches, 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?

'Use when a screener wants the newest covered pump.fun launches... already screened' gives a clear triggering context, and it states exclusions (mayhem left out, avoid-verdict launches filtered out) plus a precondition (feed lag <= 5 s, stale/empty refused). It stops short of naming a sibling to use instead when the condition is not met.

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

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

Goes well beyond the annotations by disclosing the pricing model ($0.001 per poll, empty pages cost the same), the achievable poll rate (~20 launches/min), and that a stale feed is refused before payment. These are non-obvious cost and failure behaviors an agent must know 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-loads the cost, then usage, then payload, then routing, in one dense paragraph with no filler sentences. It is information-heavy and slightly packed, but every clause carries operational value.

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, yet the description enumerates the returned item fields (creator, reserve, buys, buyer inflow, top-5 holder/creator shares, first-observed flags, verdict, P(rug within 300s), P(graduation)), so an agent knows what to expect without a schema.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning: default window of 60s, hard cap of one hour, and that `since` should carry the previous call's next_cursor. It loosens rather than restates the schema.

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 (poll/return) and resource (covered pump.fun launches after `since`), with ordering (oldest first), cap (up to 100), and the exact payload carried by each item. It clearly differentiates itself from siblings by naming recent_launches for one-off screens and check_pumpfun_risk for a single mint.

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?

Explicitly says when to use it ('when a bot polls for new pump.fun launches') and routes the two adjacent use cases to named alternatives (recent_launches, check_pumpfun_risk). It even prescribes the polling loop via 'pass next_cursor back as since'.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds real context beyond that: it is free, takes no arguments, returns JSON, and scopes the data to 'the last hour' plus 'history totals', which tells the agent what window it is observing.

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 key framing ('Free. pump.fun market regime meter') and then packs the metric list densely. The metric enumeration is long but each item is load-bearing for understanding the return payload, so it earns its place; minor density 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?

With no output schema and no parameters, the description carries the burden of saying what comes back, and it does so by enumerating the reported metrics and noting output. 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?

Zero parameters, so the schema has nothing to explain; the description correctly states 'No arguments' rather than leaving the agent guessing. Baseline for a no-param tool is 4.

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

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

States a specific verb+resource ('pump.fun market regime meter') and enumerates the concrete signals it reports (launches/min, mayhem share, curve buys/sells, migrations vs true graduations, rug flags, history totals). It also names the sibling it is not, check_pumpfun_risk, for single-mint questions.

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 when-to-use ('judge the pump.fun market as a whole') and an explicit when-not with the named alternative ('not for one mint (use check_pumpfun_risk)'). The routing decision is fully determined without opening any schema.

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 annotations present (readOnlyHint=false, openWorldHint=true, etc.), the description adds valuable context beyond them: pricing ($0.01 per page), pagination (up to 500), and the availability of summary/demand/cohort blocks. It does not contradict the annotations, but it omits rate limits or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with pricing and use case, then details returned data and inputs. While dense, the parenthetical field list is thorough but could be tightened; overall it is well-structured and informative.

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 explains the return structure: individual trades, summaries, demand and cohort blocks. It also covers pagination and cost, making it complete for an agent to call the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters in detail. The description's input summary repeats the schema without adding new syntax or constraints, meriting the baseline 3.

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 specific verb (retrieves) and resource (trades for one pump.fun token), and distinguishes it from broader tools by emphasizing 'ONE' token and trade-by-trade detail. It lists the fields returned, making the scope unambiguous.

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 clearly indicates when to use it: for trade-by-trade data on a single token or polling new trades. However, it does not name alternative tools (e.g., rhc_curve_trades) or specify when not to use it, leaving some routing ambiguity.

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

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

The description discloses pricing ($0.01 per call), the data source and freshness semantics (since 2026-09-27T00:18:34Z), the required coverage prerequisite, and a hedging caveat that labels are observations, not a verdict. Since readOnlyHint=false and idempotentHint=false are already declared, this extra billing/snapshot context is a meaningful addition rather than a restatement.

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 content is dense and largely earns its place, but it is delivered as a single sprawling sentence that front-loads the price while burying the return-structure detail. Readability and front-loading suffer despite low filler.

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

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

With no output schema, the description carries the full burden and does so: it enumerates holder fields, the concentration block (top-5/top-10 share, HHI), the cohorts block (dev, bundlers, snipers within 2s, SOL in/out) and the reputation aggregation. Combined with cost and prerequisite, an agent has what it needs to call and interpret the tool.

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

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

Schema description coverage is 100%, so both mint and limit (including the 1-100 bound and accepted link formats) are already fully documented in the schema. The description's 'Input: mint..., limit' restates rather than extends that, 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 retrieval verb and resource: 'who holds ONE pump.fun token right now', sourced from a per-wallet ledger of curve trades. The scope (single mint) and the kind of data returned (holders, concentration, cohorts) are explicit, making it easy to distinguish from siblings like wallet_profile or mint_flow.

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?

'Use when you need who holds ONE pump.fun token right now' gives a clear triggering condition, and the schema adds a prerequisite (call check_coverage first). It does not explicitly state when NOT to use it (e.g. multi-token or historical queries), so it falls 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?

Beyond annotations, it discloses pricing, deterministic fixed-rule semantics, exact label meanings, settlement delay, null-until-settled behavior, and that labels are never provisional false. This is unusually transparent behavioral context for an outcome-labeling 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?

The description is dense and front-loads price and primary use, but it is a long run-on list that could be structured more cleanly. Most content earns its place because there is no output schema, though the trailing ellipsis suggests possible truncation.

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 compensates by listing the returned outcome labels and their semantics, including settlement timing and null values. It gives enough context for an agent to know what it will receive and when the labels are valid.

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 there is only one parameter, so the schema already carries full parameter meaning. The description restates the accepted input forms but adds no syntax or constraints beyond what the schema provides, 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?

The description states a specific verb-like use (grade/backtest) and resource (outcome labels for ONE pump.fun launch), and clearly distinguishes the scope from batch or live-risk siblings. It also names check_pumpfun_risk as the live alternative, so an agent can route correctly without opening another 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?

It gives explicit when-to-use guidance: grade your own rug/graduation calls or backtest a signal, and explicitly says to use check_pumpfun_risk for a live check. It also explains the settlement timing and null behavior, which tells the agent when the tool is useful versus premature.

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

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

Goes well beyond the annotations by disclosing pricing ($0.01 per call regardless of answers), the pre-payment refusal rules (over 40, malformed, or repeated mints), the known:false behavior for unseen mints, order preservation, and the 'no probabilities, no opinions' guarantee. 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?

Front-loads the price and the core action, and every sentence carries information. Slightly dense and clause-heavy in the middle, but no filler or repetition.

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?

No output schema exists, and the description points to 'the fields and the fixed public rule of mint_outcome' rather than enumerating the returned fields, which forces a cross-reference. Everything else an agent needs to call it 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 coverage is already 100%, so baseline is 3; the description adds genuine meaning on top — accepted input forms (mint or pump.fun/gmgn/solscan/birdeye link), distinctness, ordering of returned labels, and rejection semantics. It stops short of format details, so not a 5.

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 ('outcome labels of 1 to 40 distinct pump.fun mints in the order asked') and explicitly distinguishes itself from the sibling mint_outcome by count and price. An agent can route between the batch and single-mint tools 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 a concrete use case ('grade a list of your own rug or graduation calls') and names the alternative with its selecting condition ('for one mint mint_outcome ($0.001) costs less'). The when-to-use-this-vs-that decision is fully specified.

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

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

Annotations are mixed (readOnlyHint=false, idempotentHint=false, openWorldHint=true), so they don't fully tell the agent what this does. The description adds genuinely useful context the annotations cannot: a per-call price ($0.025), the meaning of coverage full vs thin, and the specific semantics of graduation (curve witnessed >= 84 SOL). It does not clarify why a pure lookup is flagged non-read-only, which would help.

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?

Leading with price rather than purpose delays the front-loaded value, and the body is one run-on sentence of nested field names ending in an ellipsis. Because there is no output schema, enumerating return fields has some justification, but it could be structured as a compact list instead of dense prose.

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 must convey what comes back, and it does so thoroughly (flags with first-seen times, probabilities, cohorts, authorities, Token-2022 extensions). Cost, coverage tiers, and the graduation threshold are all disclosed, so an agent has enough to decide and call. The only gap is the unaddressed non-read-only annotation.

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 `mint` property already documents base58 length, the 'pump' suffix convention, and accepted explorer links. The description only restates 'ONE Solana token' and adds no format, normalization, or error-handling detail beyond the schema. 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 opening line pins the deliverable to 'every measured field for ONE Solana token,' and the field list (rug/close flags, curve truth, P(rug), creator record) makes the resource concrete. The 'ONE token' scope implicitly contrasts with the batch-oriented siblings, though no sibling is named. It reads more as a field inventory than a verb+resource statement, which keeps it out of 5 territory.

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?

'Use when you need every measured field for ONE Solana token' gives a positive trigger, and the coverage full/thin split hints at when the result will be rich. But there is no when-not guidance and no routing to cheaper alternatives such as check_pumpfun_risk, token_safety, or mint_holders, despite many siblings covering overlapping ground. Usage is implied rather than directed.

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

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

Annotations already cover safety (readOnly, idempotent, destructive=false, openWorld), so the bar is lower. The description nonetheless adds meaningful behavior: 5-second refresh cadence, list sizes (ten each), the ranking signals, and the free-vs-paid relationship. It stops short of describing rate limits or failure modes, but for a no-argument read tool this is solid added 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?

Front-loaded with the free designation and the two result sets, and every clause carries information (age thresholds, buy threshold, probabilities, cadence, count). The first sentence is dense and slightly run-on, but no sentence 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 must convey the return shape, and it does: two ranked lists of ten, each entry carrying the paid check URL and tool. The only minor gap is that exact field names/structure of a list entry are not spelled out, which is acceptable given the per-entry description.

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?

Zero parameters, so the baseline is 4 per the rubric. The description reinforces this with 'No arguments,' which removes any ambiguity about needing inputs.

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+resource: it returns two ranked lists of covered pump.fun mints (<30s by rug probability, <15min with >=5 buys by graduation probability). It also differentiates itself from the sibling check_pumpfun_risk, so an agent can tell these apart without opening 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?

Explicit routing: 'Use it to find fresh mints worth a paid check; for a mint you already hold call check_pumpfun_risk.' It names both the when-to-use condition and the specific alternative tool for the adjacent case.

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

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

Annotations supply the safety profile (openWorld, non-destructive), and the description adds substantial context on top: the per-call price, that a stale feed is refused before payment, and the exact criterion for graduated=true (curve witnessed at >= 84 SOL vs below-threshold close). This is well beyond what the structured fields disclose.

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 purpose, and every clause carries information (labels, thresholds, output shape). It is dense and semicolon-packed rather than cleanly structured, so an agent parsing it under time pressure may need a second pass.

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 return-shape burden and does so: compact cards with migrate time, pool, peak curve SOL, holder/creator labels, and the instant_bundle vs organic graduation_label. Nothing needed 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 both parameters are already documented and the baseline is 3. The description adds real meaning for window_s ('says how much the live feed saw'), clarifying it is the feed's observation window rather than a filter; limit gets no elaboration.

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 ('list recent pump.fun migrations to PumpSwap'), pins the scope (default last 6 h), and contrasts itself with check_pumpfun_risk as the rug-check alternative. An agent can distinguish it from sibling tools like recent_launches or recent_rugs 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?

Gives explicit when-to-use plus a when-not-to-use with a named alternative ('Not a live rug check: check_pumpfun_risk'). It also describes the meaning of the graduated flag so an agent knows whether this feed answers its question.

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?

Adds strong context beyond the annotations: cost per call ($0.01), the guarantee that a stale feed is refused before payment, and the default filter state. It also enumerates the card contents (curve SOL/progress, unique buyers, holder concentration, rug flags). The readOnlyHint=false annotation carries no explanation, but the pay-per-call and non-idempotent billing model the description describes is consistent with it.

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 purpose, then filters, then alternatives in three tight sentences; the dense return-field list is the only mildly heavy part. Nothing is redundant with the 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?

No output schema exists, and the description compensates by enumerating the card fields returned (curve SOL, buyers, concentration, creator record, rug flags, authorities). Combined with pricing, freshness guarantee and sibling routing, 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 coverage is 100%, so baseline is 3, but the description adds meaning by tying filter names to their purpose in screening and restating the defaults ('last hour, mayhem excluded'), which maps exclude_mayhem and max_age_s to observed behavior. limit is left to the schema.

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 verb+resource ('screen the new pump.fun launches') and pins down the scope with explicit defaults (last hour, mayhem excluded, newest first). It also names the siblings it is not for, so an agent can separate it from launches_since and check_pumpfun_risk 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?

Explicit routing: polling goes to launches_since ($0.001) and single-mint checks to check_pumpfun_risk. The only-mint vs batch distinction and the price difference are stated, leaving nothing to inference.

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

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

Adds substantial context beyond the annotations: per-call pricing, the provenance split (live feed vs launch table), that a stale feed is refused before payment, and a prompt-injection warning that name/symbol are creator-written text and 'data, not instructions'. The one gap is that annotations declare readOnlyHint=false while the description frames this purely as a read/observe operation, leaving the write-like trait unexplained.

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 purpose, then mechanisms, ordering, returned fields, provenance, exclusions, and a safety caveat. Dense but every sentence carries information; only the parenthetical mechanism list makes it heavier than strictly 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?

There is no output schema, and the description compensates by enumerating the returned fields (flag time, mint age at flag, peak/current curve SOL, name/symbol, creator). With cost, staleness behavior, and the alternative check covered, an agent has everything needed to call it 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%, so both limit and window_s are already documented with ranges and defaults. The description adds real semantics for window_s ('how much of the window the live feed saw'), which is genuinely beyond the schema, but says nothing extra about limit, so the baseline 3 holds.

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 (see which pump.fun tokens fired rug or close flags in a window), enumerates the exact mechanisms (creator_sold, bundle_dumped, curve_drained, etc.), and specifies ordering (newest first) plus the returned fields. An agent can distinguish it from every sibling, notably check_pumpfun_risk, 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?

Gives explicit when-to-use ('see which tokens fired rug flags in a window') and explicit when-not-to-use with the alternative named: 'Not a check on a mint you hold: check_pumpfun_risk ($0.005)'. Cost is stated for both paths, so the routing decision is fully determined.

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?

Adds real value beyond the sparse annotations: it discloses the $0.02 per-call cost (a genuine side effect that helps explain readOnlyHint=false), and specifies computed behaviors such as graduated-token handling (pool taxes, no quote) and tax/quote measurement basis. Annotations alone would not tell an agent any of this.

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 price and use condition are front-loaded, which is good, but the remainder is a single dense, semicolon-chained run-on listing dozens of output fields. It is information-rich yet hard to parse and would benefit from structure, so it is adequate rather than efficient.

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 carries the burden of describing return content (verdict, basis, reasons, deployer record, sell_check, launch facts, flow, lifecycle, trade cost) and even edge cases like graduated tokens. An agent knows what it will get back 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?

Schema coverage is 100% and the single address parameter is fully documented in the schema. The description only restates 'address (0x + 40 hex)', adding no format or semantic detail beyond what the schema already carries, 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 and scope: a risk/verdict card for ONE pons v2 token on Robinhood Chain, resolvable by curve or token address. The enumeration of returned fields (verdict, sell_check, launch facts) makes the tool's function unmistakable, though it never names or contrasts a sibling.

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 trigger condition: 'Use when you hold or are about to trade ONE pons v2 token on Robinhood Chain.' It even hints at input resolution (by curve or token address). No when-not guidance or named alternatives (e.g., token_safety, verdict) are provided.

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?

Discloses behavior the annotations do not: per-page pricing ($0.02), cursor-based pagination via next_cursor, freshness bound (90 min), returned state check against prior state, and the free sample route. Annotations only carry generic hints (readOnlyHint=false, openWorldHint=true), so this extra cost/pagination/freshness context is genuinely additive.

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 usage, which is good, but the field enumeration after 'in block order:' is a dense colon-chained run-on that is hard to scan. The information is mostly warranted (no output schema exists), yet the structure could be split into discrete sentences.

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 usefully enumerates the returned fields (amounts, fee, snipe/creator tax, Q and T, price Q/T, multiple vs launch, graduation share, next_cursor), and it covers cost, pagination and freshness for a 3-param tool. Only a clearer statement of failure/coverage limits 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?

With 100% schema description coverage the schema already documents address, since (cursor/block/unix seconds) and limit. The description's 'Input:' sentence largely restates those fields, adding only the framing that address may be a curve or token, which the schema also states. 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: reserves after each trade on a Robinhood Chain pons curve, rebuilt per buy, sell and fee-sweep buyback in block order. An agent can distinguish it from aggregate siblings like rhc_curve_card, though 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?

Gives clear trigger conditions ('Use when you index or price a pons curve and need the reserves after each trade') plus a scope restriction ('ETH-paired curves up to 90 min old') and a free sample endpoint to check coverage first. No explicit when-not or named alternative, so not 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 annotations present, the description adds substantial non-structured context: the $0.01 per call cost, the exact card fields returned, the fixed verdict rule and label source, and the non-coordination caveat on cluster matching. It does not explain pagination limits or rate behavior, and readOnlyHint=false sits in mild tension with a 'screen or poll' read operation, but overall the disclosure is rich.

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?

Cost is correctly front-loaded, but the body crams a long list of card fields and rule details into a single dense paragraph (and it appears truncated), which hurts scannability. Most content earns its place, but the enumeration of every returned field could be structured or trimmed.

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 return-shape duty and does list the card contents plus verdict/basis labeling, and all 7 optional parameters are addressed by the schema. Remaining gaps are minor: pagination/limit guidance in prose and explicit sibling routing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it clarifies the default time window ('last hour'), the semantics of ring_only (only curves matching the measured same-block cluster structure), and that since takes the previous next_cursor and returns oldest-first.

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: screen or poll new memecoin launches on Robinhood Chain, with the concrete scope (default last hour, newest first, chain 4663). It is clear what the tool returns (structure cards with raised, graduation progress, tax, cluster share, verdict), though it does not explicitly differentiate itself from close siblings like recent_launches or launches_screened.

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?

Embedded guidance exists: use it to 'screen or poll', ring_only 'returns only ring-shaped curves', and since returns newer launches oldest-first. But there is no explicit when-to-use / when-not / alternative-tool routing against siblings such as recent_launches or launches_screened, leaving the agent to infer selection.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world reads, so the safety profile is covered. The description adds genuinely useful context beyond that: it is free, takes no arguments, and names the metric families returned including a caveat-like 'feed health' signal. It stops short of describing freshness, rate limits, or how feed health should be interpreted.

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, front-loaded with the nature and cost of the tool, then the routing guidance. The metric enumeration is dense but each item earns its place by telling the agent what data to expect; the list is long enough to slightly dilute the core message.

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 does so: it names the metric families an agent will receive, flags the free tier, and specifies scope versus the nearest sibling. Nothing needed 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?

Zero parameters, so the baseline is 4. The description confirms 'No arguments,' which is consistent with the empty schema and removes any doubt about required inputs.

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 (Robinhood Chain regime meter, chain 4663) and enumerates the concrete metrics it reports (launches/hour, graduations, curve buys/sells, unique buyers, snipe-tax facts, feed health). It explicitly distinguishes itself from the sibling rhc_curve_card, so an agent can route between them without opening 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?

Gives a positive condition ('gauge Robinhood Chain launch activity as a whole') and a negative one ('not for one curve') paired with the exact alternative tool name (rhc_curve_card). This is the explicit when/when-not/alternative pattern.

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?

Adds real behavioral context beyond annotations: output is unsigned calldata routed by KyberSwap's aggregator, a sell requires an approval sent first, and min output plus deadline are included. The annotations (readOnlyHint true, idempotent, openWorld) are consistent with a builder that returns data rather than mutating state. The only blemish is the fee framing — 'Free.' in the description versus '0.25% disclosed fee (free)' in the title, which is ambiguous rather than a contradiction.

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 fee statement and the when-to-use rule before the mechanics, and every sentence carries information. Slightly repetitive in restating 'Robinhood Chain' and 'graduated pons token' within a single long sentence, keeping it from a 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 correctly carries the return-value burden: it names the unsigned transaction fields, the approval needed for sells, the minimum output and the deadline. Combined with 100% schema coverage and consistent annotations, an agent has everything needed to call and interpret the result.

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 every parameter already carries its own semantics (side default, decimals for amount, slippage bounds). The description adds only the side-specific meaning of amount, which is already in 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 the specific verb and resource: builds the UNSIGNED swap transaction for a GRADUATED pons v2 token on Robinhood Chain (chain 4663), and enumerates the returned artifacts (to, data, value, chain id). It explicitly names the sibling rhc_curve_card as the tool for tokens still on a curve, so an agent can route 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 the trigger condition ('when a wallet is about to buy or sell a graduated pons token ... and needs the transaction to sign') and the explicit exclusion with an alternative ('for a token still on its curve use rhc_curve_card instead'). Nothing about when-to-use is left to inference.

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

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

Annotations only flag readOnlyHint=false and idempotentHint=false; the description goes well beyond by disclosing the entire billing model (free tier, $0.01/$0.025/$0.02 price points) and the guarantee that no charge occurs when the paid answer adds nothing. It does not discuss rate limits or auth, but the cost/side-effect disclosure is exactly what the non-readOnly annotation implies and is well covered.

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 core purpose and the free tier, then layers the depth options. Dense but every clause carries information; the mid-description parenthetical pricing and the trailing input sentence are slightly heavy but not 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?

No output schema exists, yet the description describes what comes back (authorities, top holders with named pools, venue, verdict word and reason, calibrated probabilities, flags) and covers all input forms and depth modes. An agent has enough to invoke and interpret it, with only sibling differentiation and auth expectations left unstated.

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

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

Schema coverage is 100%, so baseline is 3. The description nonetheless adds real meaning beyond the enum values by spelling out what each depth buys, the prices, and the live-window condition, and by listing accepted token input forms (mint, pons 0x address, terminal link).

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 ('Pre-trade safety check for one token') and outlines the payload (mint/freeze authority, largest holders, launch venue, verdict). It is distinguishable from generic siblings, though it never names the likely-overlapping alternatives (mint_risk_card, check_pumpfun_risk, verdict) that an agent browsing the sibling list would need to compare against.

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 clear conditions for each depth mode (auto for a live pump.fun launch, free to never pay, full for a risk card) and states that nothing is bought when the paid answer adds nothing. Missing explicit routing to sibling tools such as check_batch_risk for multi-token or check_watchlist_risk for portfolios.

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

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

Goes well beyond the annotations by disclosing cost ($0.01 per call), refusal semantics ('refused before payment, nothing charged'), coverage and feed-lag prerequisites (full live coverage, lag <= 5 s), and the fact that the cohorts block is context the rule does not read. It also describes the returned verdict vocabulary and probabilities, none of which the annotations 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?

Price and usage are front-loaded, and every clause carries information (output shape, prerequisites, refusal behavior, evidence pointer). It is dense and somewhat run-on, but there is little pure filler to cut.

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?

No output schema exists, so the description must explain the return payload — and it does: verdict labels, reason line, up to three evidenced flags, two probabilities, market/authorities, and the share_url card. Combined with the refusal/prerequisite rules, an agent has everything needed to call and interpret this 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% for the single 'mint' parameter, so the schema already carries the accepted mint/link formats. The description repeats the same input contract without adding new syntax, examples, or ambiguity resolution, 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 verb+resource (a bounded rug-check verdict for ONE pump.fun mint) and enumerates the exact answer shape: 'avoid | caution | no_flags_observed', a one-line reason, flags with evidence, and probabilities. It explicitly contrasts itself with sibling check_pumpfun_risk ('Raw evidence'), so an agent can distinguish the two 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?

Clear triggering condition: 'Use when you need one bounded answer for ONE pump.fun mint you are about to buy or hold,' and it routes to check_pumpfun_risk for raw evidence and to check_coverage (via schema) as a prerequisite. It stops short of naming when-not to use it (e.g., batch cases that belong to check_batch_risk), so it is not a full 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 readOnlyHint=false and idempotentHint=false, the description supplies the context annotations cannot: per-call cost ($0.02), a refusal guarantee on stale feeds before payment, the coverage window (last 3000 mints), and the degraded result shape for unranked wallets. These are exactly the behavioral traits an agent needs before spending money or deciding whether a null result is an error.

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 cost and the primary use case, then the return contents, then the exclusion, then the input - a sensible ordering. It is dense with semicolon-chained clauses, which makes it slightly harder to scan than it needs to be, but every clause carries information and 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?

There is no output schema, so the description carries the return contract itself: class, PnL with window and build time, holdings, creator stats, funding source, and the null-class case. Combined with cost and freshness behavior, this is complete enough for an agent to call it and interpret the response without further sources.

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?

Only one parameter, and the schema already documents it at 100% coverage ('base58 Solana wallet address (32-44 chars)'). The description's 'Input: address (base58 wallet)' merely restates the schema, adding no format, encoding, or validation detail beyond it, 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 ('classify a wallet that buys pump.fun tokens') and enumerates the concrete outputs (insider/latency_bot/skilled class, realised PnL, holdings, creator stats, funding source). It also names the sibling it is not ('not a mint's rug risk (use check_pumpfun_risk)'), so an agent can separate it from mint_risk_card/token_safety without opening 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?

Gives an explicit when-to-use ('classify a wallet that buys pump.fun tokens') and an explicit when-not-to-use with the correct alternative named (check_pumpfun_risk for mint rug risk). The unranked-wallet case is also pre-empted (null class, no PnL), which prevents misuse when the wallet is not on 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?

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond annotations: it is 'Free, answered locally' and takes no arguments, and it enumerates the data returned (wallet address, USDC balance, caps, signed/settled items, tool prices). It does not explicitly state permissions or output format, but adds meaningful 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?

It is a single, front-loaded sentence that immediately states 'Free, answered locally' before listing returned data. The enumeration is somewhat long but each item earns its place by describing what the tool reports, and it remains focused.

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 compensates by listing the key return values (payment method, wallet address, USDC balance, spending caps, signed/settled activity, tool prices). Annotations cover safety traits, and 'No arguments' clarifies the empty schema. The definition is complete enough for an agent to call it correctly, though it could clarify its relationship to wallet_profile.

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 are zero parameters, so the baseline is 4. The description explicitly confirms 'No arguments,' matching the empty schema and removing any ambiguity about input requirements.

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 identifies the resource: local payment status, wallet address, balance, caps, settlement, and tool prices. It implies a read/status retrieval without a distinct verb, but an agent can tell it is about payment state. It does not differentiate from the sibling wallet_profile, which could also concern wallet information.

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 states it is 'Free, answered locally,' but gives no explicit guidance on when to use this tool versus alternatives like wallet_profile. No when-not conditions or exclusions are provided, leaving usage entirely to inference.

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

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

Annotations already declare readOnly/idempotent/openWorld, but the description adds real operational traits: it returns availability only (not event details), the cursor expires after 24 h, and there is a minimum poll interval. Those are the facts an agent needs to avoid misusing it.

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?

Five short sentences, front-loaded with cost and purpose, each carrying a distinct operational fact (price, return shape, TTL, poll rate, usage rule). 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?

With no output schema, the description supplies the return contract (availability only vs paid details), cursor lifetime, and polling guidance. An agent can call this correctly without further 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 coverage is 100%, so both mints and cursor are already documented in the schema, including the opaque-cursor and no-new-events semantics. The description only restates the 'same one to five mints' scope, adding little beyond the structured fields.

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 verb and resource: initialize a watch cursor or check for new documented risk/lifecycle events across one to five mints. The free-vs-paid split and the 1-5 mint scope make it immediately distinguishable from sibling watchlist/risk 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?

Explicitly routes usage: watch held mints for free, poll every 15 s or slower, and only buy the paid detail check when this reports new events. This is a when-to-use plus when-to-pay rule, not a vague suggestion.

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