robinx-mcp

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

Beyond the readOnly/openWorld/non-destructive annotations, the description discloses substantial behavior an agent could not get elsewhere: the response is split by epistemic status (current_state recomputed in place with NO history, so joining to a past timestamp is lookahead bias; observed on an immutable capture clock), the tool publishes inputs not predictions, and the call costs $0.03 USDC on Base or is covered by a plan key. This is exactly the extra context the lower annotation bar is meant to reward.

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 long, but front-loaded with the core purpose and almost every clause carries distinct content (content classes, epistemic caveat, cost). The parenthetical catalogue of social measurements is the densest stretch and could be trimmed, which 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?

No output schema exists, so the description must carry the return-value burden, and it does by enumerating the feature groups and the current_state vs observed split. With annotations covering the safety profile and cost/scope communicated, an agent has everything needed 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% for the single 'token' parameter (schema already documents '0x + 40 hex'), so the baseline is 3. The description adds domain scope ('Robinhood Chain token') but no format or syntax detail beyond what the schema states, so no lift above baseline.

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

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

The opening line states a specific resource and scope: 'THE FEATURE ROW FOR A TRADING AGENT. One call returns the token-level feature row for a Robinhood Chain token.' It then enumerates the exact content classes (launch facts, activity, deployer track record, price quote, social measurements), which lets an agent tell it apart from narrower siblings like robinx_mentions or robinx_token. It stops short of naming the sibling it is not, so it does not reach a 5.

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

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

Use context is implied rather than stated explicitly: 'ready to fold into your own model' and 'backtest these inputs against your own forward returns' suggest the ingestion/backtest scenario, and 'Robinhood Chain only' constrains scope. There is no explicit when-to-use-vs-alternatives guidance pointing at the ~30 sibling tools, so an agent must infer the boundary.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description usefully adds behavior annotations lack — a pricing model ($0.03 or a plan key) and the 100-transfer filtering rule — but says nothing about result shape, pagination, or whether the 100-transfer threshold is a hard filter, leaving behavioral 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?

A single front-loaded sentence carrying the core semantics, with the payment note parenthetically appended. No filler, though the cost parenthetical slightly dilutes the payload-first structure.

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 read-only lookup with no output schema and annotations covering safety, the description supplies the returned content in enough detail that an agent could decide relevance and call it correctly. The pricing note closes the last practical 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% for the single 'address' parameter, so the baseline is 3. The description implies the address must be an Arc wallet but adds no format or validation detail beyond the schema's 'Arc wallet address 0x…'.

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 ('An Arc wallet's launch record') and enumerates what it contains: tokens minted that reached 100 transfers, launchpads used, and counts reaching 1,000 transfers. This is far more informative than a tautology, but it never contrasts itself with the neighboring robinx_deployer or robinx_arc_token tools (e.g. why use this over the general deployer), so an agent must infer the boundary.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no named alternative, despite several plausibly overlapping siblings (robinx_deployer, robinx_arc_token, robinx_arc_launchpads). The only routing hint is the implicit 'Arc wallet' scope, which is weak guidance at best.

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 a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds genuinely useful behavioral context beyond them: the $0.01 cost / plan-key inclusion and the fact that results are grouped by minting-transfer thresholds. Return format and pagination behavior are still unstated.

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 scope, then specifics, then commercial terms. Dense but every clause carries information; the parenthetical pricing note is slightly trailing but legitimate.

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 returns, and it does so reasonably (100-transfer and 1,000-transfer cohorts, 24h and 7d counts, grouping by public name). An agent has enough to decide whether this answers its question, though exact response shape is not guaranteed.

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 'limit' parameter, so the schema already documents range (1-200) and default (50). The description adds nothing about the parameter, 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 (enumerate every launchpad and factory on Arc, chain id 5042) and names concrete examples (ArgusPad, RadarDEX, Uniswap's LiquidityLauncher). The 'since genesis' scope implicitly distinguishes it from the sibling robinx_arc_new_launches, though it never names that alternative explicitly, keeping it just short of a 5.

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

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

Usage is implied (list the full historical set of launchpads) but there is no explicit when-to-use, when-not, or named alternative. The pricing note tells the agent about cost, not about selection context. No prerequisites or exclusions are 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?

Annotations already cover the safety profile (readOnly, openWorld, non-destructive), and the description adds real value on top: it discloses the cost model ($0.02 or plan key) and the pagination contract (cursor comes from next_before_block on the previous page). It does not cover result ordering/staleness, but that is a minor gap given annotation coverage.

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 tool's identity and returned fields, then filtering, then paging, with the payment detail relegated to a trailing parenthetical. Dense but every clause carries information; no filler 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?

There is no output schema, but the description compensates by naming the returned fields (launchpad, sending wallet, transfer and recipient counts) and the paging cursor, so an agent can consume results correctly. Missing only ordering guarantees or a default-sort note.

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 is already documented, making 3 the baseline. The description largely restates the schema (via = launchpad filter, before_block = cursor, min_transfers), adding only the mild clarification that the cursor originates from a prior page's next_before_block.

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 ('Newest Arc token launches') and enumerates what each result carries: launchpad, minting wallet, transfer and recipient counts. This distinguishes it from siblings like robinx_arc_launchpads and robinx_arc_token, 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?

Gives concrete operational guidance on filtering (via launchpad address, min_transfers) and pagination (before_block), plus the access/pricing model. However it never states when to choose this over robinx_arc_launchpads or robinx_arc_token, so 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?

Annotations cover the safety profile (readOnly, openWorld, non-destructive), and the description adds real value beyond them: explicit scope exclusions (no price/liquidity/holder data) and cost/access terms ($0.03 or a RobinX plan key). It does not cover error behavior for unknown tokens, keeping it short of a 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?

Front-loaded with the core resource, then the field inventory, then scope exclusions and cost. Dense and every clause carries information, though the field enumeration reads as a run-on and could be tightened.

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 describe returns — and it does so thoroughly by listing the record's components. Combined with annotations covering the safety profile and the schema covering the parameter, an agent has enough to invoke correctly; only error/edge-case behavior is absent.

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 parameter with 100% schema description coverage ('Arc token address 0x…'), so the schema already carries the parameter meaning. The description adds nothing about the token argument — not its format, chain scope, or symbol-vs-address disambiguation — 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 (an Arc token's launch record) and enumerates its contents: launchpad, deployer, first pool timing, transfers, recipients, same-symbol siblings. The 'No price, liquidity or holder data' line implicitly distinguishes it from robinx_token, but sibling differentiation is by inference rather than explicit naming.

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 by the content list — an agent can infer this is for launch-provenance queries — but there is no explicit when-to-use/when-not statement or named alternative (e.g. 'for price data use robinx_token'). The pricing note is about cost, not selection guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds genuinely useful non-schema behavior: the basket is free, forward-looking, and built by a deterministic rule (entry at +30 minutes, then held), which tells the agent what the data represents and that it is not user-configurable. It does not describe response size or pagination, keeping it short of a 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?

Two short sentences, with the defining trait ('Free live forward paper-basket') front-loaded before the methodology clause. Nothing is padded, though the telegraphic style trades brevity for clarity.

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

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

For a zero-parameter read-only tool this is close, but with no output schema the description carries the burden of explaining what comes back, and it never says what a 'basket' entry contains, how many entries exist, or how current it is. The methodology is covered; the return shape is not.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and it correctly presents the tool as parameterless by describing a single fixed, pre-computed dataset rather than implying filters.

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

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

The description identifies the resource as a 'live forward paper-basket' record and describes its construction rule ('every launch from a proven deployer, entered +30min, held'), which is more than a restatement of the name. However, it is a dense noun phrase heavy with internal jargon ('forward', 'proven deployer', 'RobinX signal') and never states in plain terms what the tool returns or how it differs from adjacent tools like robinx_stats, robinx_leaderboard, or robinx_signals.

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

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

There is no explicit when-to-use guidance and no mention of any alternative tool. The phrase 'The forward public track record of the RobinX signal' implies this is the historical-performance view, but the agent must infer that against roughly thirty siblings with no routing help.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds genuinely useful behavioral context beyond them: it is free, measured against real on-chain prices since chain genesis, and calls are 'preserved as captured, so deletion does not scrub the record' — a meaningful data-provenance and immutability 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?

Purpose and data provenance are front-loaded, followed by the field enumeration and the call-to-action. The field list is dense but earns its place by previewing the return shape in the absence of an output schema; a minor amount of phrasing could be tightened.

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 enumerating the returned metrics, and annotations cover the safety profile. For a single-parameter read tool this is nearly complete; only the contrast with sibling caller tools and any rate/cost caveats are 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?

There is a single parameter with 100% schema description coverage ('X handle, with or without @'), so the schema already carries the semantics. The description implies any X account is accepted but adds no formatting or edge-case detail beyond the schema, which is the expected baseline.

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

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

The description states a specific resource (a measured track record for an X account that calls Robinhood Chain tokens) and enumerates the exact outputs (early_rate, momentum_rate, median 1h return, cluster flag, recent calls). This clearly distinguishes it from siblings like robinx_caller_calls (raw call list) and robinx_callers (caller roster).

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 one implied usage condition — 'Use before trusting any "alpha caller"' — which tells the agent when this is valuable. However, it never names an alternative or exclusion, e.g. it doesn't say to use robinx_caller_calls for the raw list versus this for the aggregate verdict, so routing between siblings 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 already cover the safety profile (readOnly, non-destructive, openWorld), and the description adds genuinely useful behavior: records are preserved as captured so deleting the post does not scrub the record, truncation is flagged, and the call costs $0.02 USDC on Base (or a plan key). Missing: rate limits and how pending/ungradeable states resolve over time.

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 long field enumeration is defensible because no output schema exists, but the cost is stated twice ('Costs $0.02 USDC on Base. (paid $0.02, or included in a RobinX plan key...)'), which is redundant, and the single sprawling sentence buries the payload behind a metaphor ('the receipts behind the free Caller Report Card').

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 thoroughly (post id/URL, capture time, attribution basis, pool, three prices, moves, grade or reason for none, token outcome, totals). Payment and persistence caveats are covered; only rate/refresh behavior is absent.

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, fully documented in the schema at 100% coverage ('X handle, with or without @'). The description restates that scope ('by one X handle') without adding format or validation detail beyond the schema, 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+scope: the most recent 100 Robinhood Chain calls by one X handle, with an enumerated field list. It is clearly the per-handle call log, distinguishable from the aggregate robinx_callers/robinx_caller siblings, though it never names those siblings explicitly.

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

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

Usage is implied — you call this to see a given handle's recent call history — but there is no explicit when-to-use versus robinx_caller (profile) or robinx_callers (list), and no stated prerequisites. Payment context is mentioned but routed out to 'see instructions'.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful context beyond them: the cost ($0.01 or a RobinX plan key), the ranking methodology and why a 3-of-4 record ranks below 10-of-19, the evidence-label grading, and the fact that the governing rules are returned in the response.

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

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

The core definition is front-loaded in the first sentence, with methodology, output fields, and pricing following in a logical order. It is dense and the parenthetical pricing clause is somewhat 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 compensates by enumerating the returned fields (rank_score, early_rate, median 1h move, graded-call count, evidence label, rules) and disclosing cost. Combined with annotations covering the read-only/open-world profile, an agent has enough to decide and call it; only the sibling-level routing against robinx_leaderboard is unaddressed.

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

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

The tool takes zero parameters, so the schema-description baseline is 4 and there is no parameter semantics to explain. The description does not misrepresent any input, though it also cannot add anything here.

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 gives a specific verb+resource: an X caller leaderboard for Robinhood Chain, with the ranking metric (rank_score, the 95% Wilson lower bound) spelled out. It is clearly distinct in content from robinx_caller/robinx_caller_calls, but it never explicitly states how it differs from the sibling robinx_leaderboard, so it falls 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?

Usage is only implied. 'Measured, not follower count' hints that this is the credibility-weighted alternative to a follower-based ranking, and the pricing note implies a cost decision, but there is no explicit when-to-use, when-not-to-use, or named alternative tool.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context by disclosing cost ($0.01 or included in a plan key), which an agent needs before calling. It stops short of describing rate limits or response shape.

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 return-field list is front-loaded and the pricing note is tucked into a trailing parenthetical. Two sentences and a parenthetical, each doing work, though the stock_issuer aside is somewhat tangential given it is not a sibling tool.

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

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

There is no output schema, so the description correctly compensates by enumerating the returned fields and the 0-100 score. Combined with annotations covering the safety profile and the disclosed cost, an agent has enough to call it correctly; only edge details like chain scope or error behavior are absent.

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 a single parameter and 100% schema description coverage ('Deployer wallet 0x…'), the schema already carries the semantics. The description adds no format, chain, or validation detail beyond what the schema states, 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?

The description names a specific resource ('Deployer reputation record') and enumerates exactly what it contains: tokens launched, real vs dead, best-token volume, insider-distribution flag, and a 0-100 score. It further disambiguates by contrasting with stock_issuer, so an agent can tell it apart from token/wallet/issuer siblings.

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

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

Usage is only implied: it is clearly a per-deployer lookup keyed by wallet address, and the stock_issuer note gives one routing distinction. However, stock_issuer is not in the sibling list, and there is no explicit statement of when to prefer this over robinx_token, robinx_wallet, or robinx_arc_deployer.

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

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

Annotations already declare readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely useful non-schema behavior: a $0.05 USDC-on-Base cost, plan-key inclusion, and the fact that the archive is recorded live and cannot be rebuilt retroactively (a data-freshness caveat).

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 behavior in the first clause, then supporting detail. Minor redundancy in restating the $0.05 cost twice ('Costs $0.05 USDC on Base' then 'paid $0.05'), but otherwise tight and well ordered.

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-param read tool with no output schema, the description adequately covers what comes back (balances, identity, insider/deployer records), the payment requirement, and a data-retention caveat. Only the explicit distinction from sibling wallet tools 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 a single required parameter at 100% schema coverage, the schema already documents 'address (Wallet address 0x…)'. The description adds no format, validation, or chaining detail beyond confirming the subject is a wallet, 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 gives a clear verb+resource ('Follow a wallet across the accumulated holder-snapshot archive') and enumerates the returned payload (per-token balance then/now, ENS/Farcaster identity, insider/deployer records). It is distinguishable from generic detection siblings, though it never explicitly contrasts itself with closely named tools like robinx_wallet, robinx_identify, or robinx_wallet_receipt.

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 implies the use case (tracing a wallet's appearances across the snapshot archive) but offers no explicit when-to-use/when-not guidance and no named alternatives among the many sibling tools. The reader must infer this is the right pick over robinx_wallet or robinx_identify.

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

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

Annotations only cover the read-only/open-world safety profile; the description adds substantive behavior beyond them: the deployer-reputation scoring model, the tokenized_stock labelling and exclusion, the polling design, and the $0.01 cost or plan-key entitlement. Pricing/auth and scoring semantics are exactly the context annotations cannot express.

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 scoring model, then parameters, then cost. Dense but every clause earns its place; the parentheticals add real information rather than 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?

No output schema and no annotations beyond safety, so the description must cover params, behavior, and access cost — and it does all three for a curated feed. Return shape and pagination behavior past the 'since' cursor remain unspecified, a minor gap for a polling 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?

With 0% schema description coverage and three undocumented string params, the description carries the burden and largely meets it: it defines min_score semantics ('70 = proven deployers only'), identifies since as a cursor, and bounds limit at 100. It does not explain cursor retrieval or the string type of limit, but meaning is added well beyond the bare 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+resource: newest Robinhood Chain launches scored by deployer reputation, plus the tokenized_stock exclusion rule. This distinguishes it by chain scope from generic launch siblings like robinx_arc_new_launches, though it does not name an alternative tool 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?

It gives strong per-parameter usage guidance (min_score=70 means proven deployers only, since is a cursor, limit maxes at 100) and notes the tool is designed to be polled. However, it never says when to choose this over a sibling such as robinx_arc_new_launches or robinx_new_launches, so alternative selection 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 provide readOnlyHint, openWorldHint, destructiveHint. The description adds key behavioral details: only watched accounts are considered, and the provenance of 'already_following_when_tracking_began' with null followed_at is honestly stated, beyond annotation scope.

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

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

The description is two sentences, front-loaded with the core purpose, and each sentence adds essential information. No fluff; highly 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?

Given a simple tool with one parameter and no output schema, the description fully explains what the tool does, its scope (only watched accounts), and data provenance. No gaps for the complexity level.

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

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

Schema coverage is 100% with one parameter 'handle' described as 'X handle, with or without @'. The description reinforces this (given X handle) but does not add significant meaning beyond the schema, 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?

The description clearly states it checks which watched Robinhood Chain principal accounts follow a given X handle, including since when and history. This is specific and distinguishes from sibling tools like robinx_follows (which shows who a principal follows) and robinx_entity (more general).

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

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

The description implies a 'free check' for quick lookup but does not explicitly state when to use this tool versus alternatives like robinx_follows or robinx_entity. No when-not-to-use guidance or prerequisites are mentioned.

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

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

Goes well beyond the readOnly/openWorld/non-destructive annotations: 6-hour polling cadence, baseline edges that pre-existed tracking and are never reported as dated follows, crossing of newly-followed handles with measured RobinX caller records, and the $0.02 USDC on Base cost with plan-key alternative. These are exactly the behavioral caveats an agent needs and none are derivable from the annotations.

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

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

Front-loads the core purpose and the historical-uniqueness rationale, then layers filtering and pricing. Mostly dense and useful, though the trailing parenthetical pricing/plan-key sentence and the caller-record crossing clause make it longer than strictly needed for selection.

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 return-value burden and does reasonably: it describes timestamped events, baseline marking, and enriched caller records. It stops short of describing the actual response fields or confirming a returned pagination cursor, which is the main gap for a pollable endpoint.

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. The description largely restates what the schema already documents ('since=<cursor>', 'watched=<handle>', 'event=follow|unfollow') and adds no format or edge-case detail beyond the schema — e.g. it does not clarify whether the response returns a new cursor, despite mentioning cursor polling.

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 ('follow/unfollow transitions') and narrows scope precisely to 'X accounts that matter on Robinhood Chain — the chain's principals and launchpad accounts'. It also gives cadence (every 6 hours) and event form (timestamped events), which makes it clearly separable from generic follow tooling like robinx_followed_by.

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

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

Provides clear context for when this is the right tool: X exposes only current following state, so historical transitions cannot be reconstructed later — implying this is the durable-history source. It also explains how to consume it ('Pollable with since=<cursor>'). However, it never names an alternative sibling or states a when-not/exclusion condition, so it falls short of explicit 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?

Annotations already declare readOnly/openWorld and non-destructive, so the bar is lower; the description adds real value beyond them — counts only, wallets never identified (privacy), the exact fields returned, and a cost/auth model ($0.02 USDC on Base or covered by Alpha/Omega keys). No contradictions with the read-only annotation.

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?

Reasonably front-loaded with the core definition, but the dense single-sentence style is hard to parse and the pricing statement is duplicated ('Included on Alpha and Omega keys; otherwise $0.02 USDC on Base' then again in parentheses). One redundant sentence costs it.

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 list the fields (wallets, buys, WETH, first/last buy, template_launch). Privacy, cost, and framing caveats are covered, leaving only 'template_launch' under-explained.

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 all four parameters documented, and the description merely restates the same defaults (60 minutes, 3+ wallets, 0.05+ WETH). Baseline 3 is appropriate since 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+resource: tokens that multiple distinct wallets bought within a window, drawn from the RobinX wallet tape, with returned fields listed. It is genuinely distinguishable from generic signal siblings, though it never names a specific alternative tool to route 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 operational defaults and a caution ('An observation about buying, not a signal to trade'), which implies the intended framing. But it never says when to prefer this over apparent neighbors like robinx_smart_holders, robinx_pulse, or robinx_signals, leaving the routing decision to inference.

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds significant behavioral context: matching algorithm details (exact ticker or ±20% band with volume rank), cross-chain resolution via DexScreener, and pricing (5 free/day then $0.02 USDC). No 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?

The description is somewhat long but well-structured and front-loaded with the main action. Every sentence adds value. Could be slightly more concise, but no wasted words. Effective communication.

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

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

Given the complexity (image recognition, live matching, cross-chain), the description is complete: explains matching logic, confidence score, alternates, and pricing. No output schema but description gives adequate output hints.

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%. The description adds extra meaning for the 'image' parameter: 'Pass image as base64 (raw or data: URL)', clarifying the format beyond the schema. For 'media_type', no additional meaning beyond schema. Baseline 3 raised to 4 for image clarification.

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

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

The description clearly states the tool's purpose: paste a crypto price-chart screenshot and identify which Robinhood Chain token it shows. It specifies the method (Vision reads ticker/price, matches against live data) and differentiates from siblings by being the only image identification tool.

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

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

The description provides explicit guidance on when to use (screenshot) and how (pass base64). It also mentions handling of charts from other chains (detects and resolves cross-chain). However, it does not explicitly state when not to use or suggest alternatives, but given siblings, no alternative exists.

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

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

Annotations already cover the safety profile (readOnly, non-destructive), and the description adds genuinely non-obvious behavior: the call costs $0.01 USDC on Base or is covered by a RobinX plan key. It stops short of describing result size/limit or caching, which would be useful for an openWorld query.

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 result definition and efficiently sized. The trailing parenthetical repeats the pricing already stated in the prior sentence, a minor 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?

For a zero-parameter tool with no output schema, the description conveys what is returned and the payment requirement. It omits practical details like how many deployers come back or whether results are cached, but nothing needed to invoke it 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate, and the inclusion threshold (>= 70) is stated as a fixed rule rather than a filter argument.

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 (highest-reputation deployers on Robinhood Chain), the ranking basis (full-history score >= 70), and the returned fields (launch counts, track record). This distinguishes it from the single-entity sibling robinx_deployer and from the broader robinx_callers/leaderboard-style 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?

No explicit when-to-use or when-not-to-use guidance, and no routing to siblings such as robinx_deployer for a single address. Usage is only implied by the leaderboard framing.

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

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

Annotations already cover the safety profile (readOnly, openWorld, non-destructive), yet the description adds genuinely useful operational context: a $0.02 USDC cost on Base, plan-key inclusion, and the fact that tweet text is never redistributed. It still omits what the 'cluster flag' means and whether results paginate.

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 return payload is front-loaded, which is good, but the sentence is a dense run-on list and the cost clause is redundantly repeated ('Costs $0.02 USDC on Base. (paid $0.02, or included in a RobinX plan key…)'). It earns most of its length but wastes some on duplication.

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

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

With no output schema, the description carries the full burden of explaining returns and does so thoroughly (payload contents, totals, truncation flag, velocity). For a one-parameter read tool the gaps are minor: undefined jargon like 'cluster flag' and no note on ordering or pagination.

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 'token' parameter, which the schema already documents as a 0x… contract address. The description adds only the framing that the token is a Robinhood Chain token, which is marginal value over structured data; 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 states a specific verb+resource ('latest 200 X mentions of a Robinhood Chain token') and enumerates the attached aggregates (accuracy record, velocity, first-ever mention, voice counts), so the agent knows exactly what this returns. It does not, however, differentiate itself from plausible siblings like robinx_social_momentum, robinx_feed, or robinx_signals, leaving the agent to infer which social tool fits.

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

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

There is no explicit when-to-use guidance, no stated prerequisites beyond cost, and no named alternative. The reader can infer it is the tool for per-token mention data, but nothing routes the agent between this and the several other social/signal siblings.

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

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

Annotations already cover safety (readOnly, non-destructive, openWorld), so the bar is lower; the description adds real value beyond them: the paywall ($0.05 USDC on Base vs. an Omega key), the idempotent echo-counting rule, that rooms are counted but never named, and the exact output fields (verdict, launch template, LP custody, depth, +1h/+6h/+24h outcome). Missing: pagination/cursor behavior and rate-limit 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-loads the core definition and packs the criteria into one dense paragraph with no filler. The closing parenthetical repeats the pricing already stated one clause earlier, which is minor waste but the only real 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?

With no output schema, the description carries the return-value burden and does so by enumerating the receipts, checks, and measured outcomes a signal contains. Payment mechanics are covered; only cursor/pagination behavior is left unexplained.

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 all four parameters are already documented in the schema; baseline is 3. The description paraphrases the flag-check semantics behind exclude_flagged but adds no syntax, format, or defaults 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?

Names the resource (Robinhood Chain tokens) and the exact convergence rule (≥1 X call + ≥3 Telegram rooms within 60 minutes), which is far more specific than the title alone. It implicitly separates itself from siblings like robinx_signals or robinx_tg_first_call by stating its own detection criteria, though it never names an alternative tool.

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

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

States 'An observation, not a trade call' and discloses the cost, which frames intent and commitment. But it gives no guidance on when to prefer this over robinx_signals, robinx_social_momentum, or robinx_tg_first_call, and no exclusion conditions.

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

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

Annotations already declare readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context the annotations cannot: it is an aggregating synthesis (X + RobinX caller-lift + on-chain), it is 'skeptical by design', and it costs $0.04 or is covered by a plan key — cost/payment behavior is material for an agent deciding whether to call 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?

One dense but front-loaded sentence that leads with the core capability, plus a short parenthetical for cost/entitlement. Every clause carries information (outputs, data sources, stance, price) and nothing is padded.

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

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

No output schema exists, so the description carries the return-value burden — and it does enumerate what comes back (narrative, sentiment, conviction, red flags, early-caller activity). Combined with the payment note and read-only annotations, an agent has enough to call it correctly, though the lack of any routing guidance among the many sibling tools leaves a small gap.

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

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

Single required parameter with 100% schema coverage ('Token contract address 0x…'), so the schema already documents the input. The description adds only the scope qualifier 'Robinhood Chain token', which is marginal beyond the structured field. 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+resource (real-time X synthesis for a Robinhood Chain token) and enumerates the outputs: narrative, sentiment, conviction, red flags, proven early-caller activity. The 'not follower counts' contrast hints at differentiation, but it never names the siblings it competes with (e.g. robinx_social_momentum, robinx_verdict), so an agent must still infer its place in the family.

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 only implied: reach for it when you want a fused social read on a Robinhood Chain token. There is no explicit when-to-use vs when-not, nor any pointer to the alternative tools (robinx_signals, robinx_verdict, robinx_social_momentum) that also cover token sentiment.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so safety is covered. The description adds genuinely new context: cost ($0.05 or plan key) and the conditional nature of one section ('supply-forensics results if computed'), which tells the agent output varies by token.

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

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

Front-loaded with the core purpose, then the enumerated contents, then the usage claim and cost note. The long content list is justified because it defines the tool's value, though the parenthetical cost/plan note is slightly buried and could be tightened.

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 return-value disclosure and does so thoroughly by naming every report section. Still, it gives no sense of result size or formatting, and the pricing pointer to 'see instructions' is a dangling reference an agent cannot act on directly.

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 'token' parameter, so the schema already carries the syntax ('Token contract address 0x…'). The description adds no format, validation, or chain-scoping detail beyond what the schema states, making baseline 3 appropriate.

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

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

States a specific verb and resource (a FULL token report) and enumerates its components: composite verdict, deployer record, launch history, token vitals, X callers with metrics, paper-basket status, supply forensics. The phrase 'in one call' and 'the single best first call' distinguishes it from narrower siblings like robinx_token, robinx_verdict, and robinx_deployer.

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 single best first call on any Robinhood Chain token' gives clear positive guidance on when to reach for it. It stops short of naming exclusions or the specific narrower siblings to use instead when only one slice is needed, so it lacks explicit when-not guidance.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, but the description adds value by explaining the ranking order (real + liquid first) and the symbol-collision warning about scammers. No contradictions.

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

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

Two sentences with no wasted words. Front-loaded with the action and purpose. Every sentence contributes useful 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 simple one-parameter search tool with annotations, the description covers the input, output (ranked candidates, warning), and usage context. Missing details like pagination or limit are not critical given the tool's nature.

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 parameter q, with description '$SYMBOL, name, or 0x address'. The tool description reinforces this and adds context about the search behavior (free text, ranking). This adds meaning beyond 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?

The description explicitly states that the tool searches tokens by symbol, name, or address, and returns ranked candidates with a warning. This clearly distinguishes it from sibling tools like robinx_token or robinx_report, which deal with specific token data or reports.

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 advises using this tool before buying a report or verdict to resolve token identity due to scams. While it doesn't explicitly list alternatives, it provides clear context for when to use this tool.

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

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

Annotations already declare readOnly/openWorld/non-destructive, so the safety profile is covered. The description goes further with genuinely useful behavioral context the annotations lack: a $0.02 USDC on Base cost, the plan-key alternative for payment, and the important caveat that 'a measured record describes past calls, not future ones.' Rate limits and refresh cadence are not stated, keeping this short of a 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?

Front-loaded with what the stream is, followed by the filter criterion, payload, caveat, and cost. It is dense with jargon ('caller-rules-2', '95% Wilson lower bound') but every clause carries information; only mild tightening is possible.

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 accepts the burden of describing returns and does so ('Each item carries the caller's full measured record ... + the token's deployer score and FDV'). Cost and payment path are also covered. Pagination beyond the simple cursor, and any rate/cadence expectations, are the remaining gaps.

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 limit, since, min_early_rate, and min_rank_score. The description reinforces the rank_score/Wilson-lower-bound semantics and the 0.3 default but adds no syntax, formatting, or interaction detail beyond the schema. Baseline 3 is appropriate 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+resource: a pollable stream of fresh Robinhood Chain calls, filtered to X accounts with a measured early-call record. The filtering criterion (rank_score >= 0.3 / grade B) and the item payload are concrete. It does not name which sibling (e.g. robinx_feed, robinx_caller_calls) it should replace, so the differentiation is implicit rather than explicit.

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 filter semantics, and 'Pollable' plus the cursor wording suggest a continuous-polling pattern, but there is no explicit when-to-use / when-not-to-use guidance and no alternative tool is named. An agent must infer that this is the filtered 'signals' view versus the broader feed/caller tools.

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

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

Annotations already cover readOnly/openWorld/destructive, so this is a safe read. The description adds material conduct context beyond annotations: a $0.05 USDC cost on Base, plan-key inclusion, and the percentile basis (4,000+ indexed wallets). This is genuinely useful for deciding whether to invoke a paid tool, though it omits latency/refresh 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 main payload (what is returned, interpretation caveat) is front-loaded, and the description is dense but largely waste-free. The payment line is slightly redundant, stating the $0.05 cost twice across two 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 carries the burden of describing returns and does so: extraction history with percentile, deployer track records, and ENS/Farcaster identity. Combined with the cost and interpretation notes, an agent has enough to invoke it correctly, missing only explicit routing against 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?

Only one parameter exists and schema coverage is 100%, so the schema already documents 'token' as a 0x… contract address. The description adds no additional syntax or format meaning beyond that, so a 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 specific resource and scope: wallets in a token's notable holder set that have a measured off-market extraction/deployer record on Robinhood Chain. This is clearly distinguishable from a plain holder list or wallet lookup. It stops short of naming the sibling it should be chosen over (e.g., robinx_token, robinx_wallet), so differentiation is inferred rather than explicit.

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 interpretive guidance ('strong signal, ambiguous direction... not a buy call'), which helps the agent frame results, but it never states when to call this versus siblings like robinx_token or robinx_deployer. Usage is implied by the described output rather than prescribed.

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

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

Annotations already declare readOnly, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavior: the $0.02 USDC-on-Base cost, the plan-key alternative, and the cluster-collapsing ranking logic. No return-format detail, but the cost and methodology disclosures are real value beyond the annotations.

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

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

Front-loads the ranking methodology, then differentiator, window, and cost in tight succession. Slightly dense but every clause carries information; the payment parenthetical is a minor appendage.

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 tool with no output schema, the description covers purpose, scope, window bounds, and the important payment model. It could sketch the returned fields, but the essentials for correct invocation are 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 100% and the single parameter is fully documented in the schema ('lookback window in hours, 1-48 (default 6)'). The description repeats that same window/default information without adding format or behavior 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 resource (Robinhood Chain tokens) and the exact ranking methodology: caller-accuracy weight, then independent voices, then mention count, with cluster collapsing. The phrase 'Attention QUALITY, not raw hype counts' distinguishes it conceptually from hype-based siblings, though it never names an alternative tool outright.

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 framing 'Attention QUALITY, not raw hype counts' implies the intended use case, but there is no explicit when-to-use or when-not guidance and no sibling named (e.g. robinx_leaderboard, robinx_mentions). Usage must be inferred from the ranking description.

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

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

Annotations already declare readOnly/openWorld/non-destructive, so the safety profile is covered; the description adds genuinely useful context beyond them — the $0.03 USDC cost on Base, the plan-key alternative, the 45,504-wallet scope, and the found:false failure mode. It stops short of describing freshness or rate limits.

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?

Dense and front-loaded, leading with what the receipt is before qualifications. Slight redundancy in restating the price twice ('Costs $0.03 USDC on Base' then '(paid $0.03, or included in a RobinX plan key)') costs a point.

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 and does so by naming the key fields and the found:false case. It is complete enough to call correctly, though the exact response shape remains unpinned.

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 documented as base58 in the schema, so the description adds no parameter-level meaning beyond it. Baseline 3 for near-complete schema coverage with a one-param surface.

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 (chain-derived receipt for a Solana wallet) and enumerates what it contains (FIFO realized PnL in USD, win rate, hold style, open bags). It scopes itself to the 'fomo-routed' universe and implicitly separates from the sibling robinx_wallet by noting it is not the wallet's full history, though it never names that sibling directly.

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 usage context: the data covers activity through that venue only, unknown wallets return found:false, and there is a stated price/payment path. No explicit 'use X instead of Y' routing, but the venue limitation gives enough to decide when this tool applies.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is clear. Description adds specific metrics returned but doesn't disclose additional behavioral traits (e.g., caching, rate limits, data freshness). It does not contradict annotations.

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

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

Single sentence, front-loaded with 'Free coverage stats for RobinX', lists all metrics without redundancy. No wasted words.

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 no parameters, no output schema, and a simple purpose, the description covers essential information. It could mention output format or update frequency, but the lack is not critical for a straightforward stats 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?

No parameters exist (empty input schema, 100% coverage). Description does not need to add parameter meaning. Baseline 4 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?

Description clearly states it provides 'coverage stats' for RobinX and lists specific metrics (deployers scored, tokens indexed, etc.). Verb is implicit but clear. Distinguishes from siblings like robinx_deployer or robinx_token by being a general stats endpoint.

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 guidance on when to use this tool vs alternatives. It describes what it does but not the context (e.g., 'Use this to get an overview; for specific token details see robinx_token'). With many siblings, some usage advice would help.

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 readOnly/openWorld annotations: it discloses the two-call async pattern, first-call-is-free vs $0.03 pricing, plan-key inclusion, and ~10-60s latency. It also explains what a label means ('a wallet with no record carries no label') and the collapse of multi-wallet entities — behavioral detail annotations cannot express.

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 resource and scope, and every clause carries real information (labels, verdict, two-call flow, cost). It is dense and packed with nested parentheses, which slightly impedes parsing, but little is wasted for a tool with this much behavior to 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?

For a complex tool with no output schema, the description compensates by describing the return content (per-wallet labels, structure verdict) and the full invocation lifecycle (queue, wait, recall, price). An agent has enough to call it correctly and interpret results.

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 only one parameter and the schema already documents it fully at 100% coverage ('Token contract address 0x…'). The description only situates it as 'a Robinhood Chain token,' adding little syntax or format meaning beyond the schema, 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 ('Labeled holder-structure diff for a Robinhood Chain token') and enumerates exactly what it produces: who froze/added/trimmed/exited plus a rotation-vs-distribution-vs-accumulation verdict. This distinguishes it from generic siblings like robinx_token or robinx_smart_holders 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 concrete operating guidance — 'first call queues the scan (free, ~10-60s); call again for results' — and hints at scope differentiation via 'the repricing-or-rug call price data cannot make.' It does not, however, explicitly name an alternative tool for related holder questions, so routing is implied 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?

Annotations cover only the safety profile (readOnly, non-destructive, openWorld), and the description adds substantial context beyond them: source rooms are never identified, no message text is returned, a room count is included instead, every response carries corpus_through for freshness, the distribution is bimodal, and the cost is $0.03 USDC. This is exactly the kind of behavior 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?

The core definition is front-loaded in the first sentence and the rest is dense, earning its place. The pricing clause is slightly redundant ('Costs $0.03 USDC on Base. (paid $0.03, or included in a RobinX plan key — see instructions)'), restating the same figure twice.

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

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

There is no output schema, so the description must carry return-value burden, and it does: the two timestamps, the signed lead, the room count, corpus_through, and the corpus-wide aggregate note are all described. Nothing an agent needs to interpret the response 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?

Only one parameter (token) and schema coverage is 100%, with the schema already documenting it as a '0x…' Robinhood Chain token address. The description adds 'one Robinhood Chain token' but no format or scoping 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?

States a specific verb and resource — cross-venue first sighting for one Robinhood Chain token — and enumerates the exact outputs (first Telegram timestamp, first X timestamp, signed lead in minutes). This is clearly distinguishable from siblings like robinx_mentions or robinx_social_momentum, which deal with raw mentions or momentum rather than first-sighting ordering.

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

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

The description implies when it's useful (deciding which venue called a token first) and warns to use the per-token number rather than the corpus average, but it never explicitly names an alternative sibling or states when NOT to use it. Usage is inferable rather than guided.

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

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint, so the safety profile is covered. The description adds value beyond that by disclosing the $0.01 cost / plan-key inclusion and an important edge case: the deployer score is null-with-basis for Robinhood's tokenized stocks (a market, not a launch, flagged in the `stock` field). Cost and null-return behavior are genuine additions.

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 stat list in a single, waste-free sentence. The nested parentheticals (deployer-score exception, then pricing) make it denser than ideal, but every clause carries information and nothing is 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 usefully enumerates the return fields (swaps, volume, traders, activity flag, deployer score) and covers pricing and the tokenized-stock edge case. For a one-parameter read-only endpoint this is close to complete; only the absence of any sibling-differentiation or usage trigger holds it back.

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 `address` parameter is fully documented in the schema ('Token contract address 0x…'). The description adds no formatting, chain, or validation detail beyond 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?

The description names a specific resource ('Robinhood Chain token') and enumerates the exact stats returned: swaps, WETH volume, unique traders, real-activity flag, deployer score. That is far more than a tautology. It stops short of distinguishing itself from close siblings such as robinx_arc_token or robinx_arc_deployer, leaving the agent to infer which token endpoint applies.

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, no exclusions, and no named alternative among the many sibling tools. The closest thing to guidance is the pricing note ('paid $0.01, or included in a RobinX plan key'), which concerns billing, not tool selection. An agent cannot tell from this text when robinx_token is preferable to robinx_arc_token.

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

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

Annotations already declare readOnlyHint, openWorldHint and non-destructive behavior, so the safety profile is covered. The description adds genuinely new context beyond the annotations: the tool costs $0.02 (or is bundled in a plan key), and it functions even on tokens launched seconds ago, including the special tokenized_stock case where no deployer judgment applies.

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 deliverable and every clause carries information (signals, edge cases, pricing). However, the deeply nested parenthetical enumerating six signal values plus the tokenized_stock exception makes it a single hard-to-parse run-on 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 does the work of enumerating the possible verdicts and noting results come 'with reasons', and it discloses cost. For a single-parameter read tool this is close to complete, though the shape of the reasons payload is only gestured at.

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 schema coverage is 100%, so the schema fully documents the 0x contract address input. The description adds no syntax or format detail for the token argument, leaving the baseline 3 appropriate.

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

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

States a specific deliverable — a composite BUY-RISK verdict combining deployer reputation, insider-distribution flags and on-chain activity into one of six enumerated signals. This clearly differentiates it from raw-data siblings like robinx_token, robinx_deployer and robinx_smart_holders, whose outputs it aggregates.

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 one implicit usage cue — 'Works on a token that launched seconds ago (scores WHO deployed it)' — which signals it is appropriate for brand-new tokens where deployer attribution matters. It never says when not to use it or names a sibling alternative, so routing still requires inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by detailing the specific data returned (deployer record, insider-flow history, WETH realized, ranking), though it could mention data freshness or rate limits.

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 effectively summarize the tool's purpose and output, with no wasted words. The key information is front-loaded.

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

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

For a simple query tool with one parameter and no output schema, the description adequately covers what the tool returns. A brief note on response format would improve completeness, but it is sufficient as-is.

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 coverage for the single parameter 'address', the schema already documents it. The description does not add further meaning beyond 'Wallet address 0x…', hence a baseline score of 3 is appropriate.

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

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

The description clearly states the tool provides 'free wallet reputation for any Robinhood Chain address' including deployer record and insider-flow history, and labels it as the 'who is this wallet' call, which distinctly separates it from sibling tools like robinx_token or robinx_deployer.

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

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

The description implies usage for checking wallet reputation but does not specify when to use this tool versus alternatives or provide any exclusions, leaving the agent to infer 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?

Annotations already cover safety (readOnlyHint=true, destructiveHint=false), so the description's value is in the extra context it adds: it discloses cost ($0.03 USDC on Base, or plan key), a 100-wallet coverage limit, and the negative-result behavior (found:false) still billed. That is substantive beyond the annotations, though it does not describe error modes or return shape in detail.

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 metrics are front-loaded, and the sentences are dense with no filler. The pricing is stated twice ('Costs $0.03 USDC on Base. (paid $0.03, or included in a RobinX plan key…)'), a minor redundancy that 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 carries the return-shape burden and does so reasonably (PnL, win rate, hold style, open bags marked two ways). Coverage, pricing, and the unknown-address case are all covered, and as a read-only tool there are no mutation or reversibility concerns to disclose.

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 address parameter is documented structurally. The description adds meaningful semantic constraint beyond the schema: only addresses within the tracked 100-wallet roster are valid, and outside ones yield found:false. That is real parameter-domain information, above the baseline-3 for fully covered schemas.

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 concrete verb+resource ('Chain-derived trading record for a Robinhood Chain wallet') and enumerates the specific metrics returned (realized PnL in WETH across v2/v3/v4, win rate, hold style, open bags). Naming the chain distinguishes it from the robinx_solana_wallet_receipt sibling without either schema being opened.

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 scope (Robinhood Chain wallet, tracked roster of 100) but there is no explicit when-to-use/when-not or named alternative to route on. The roster and found:false note hint at the valid domain, but the agent must infer selection vs the Solana receipt itself.

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