0xrhXBT — Robinhood Chain Intelligence

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

With no annotations present, the description carries the full disclosure burden and does well: it reveals the fail-closed read semantics, the 'unmeasured is never zero' convention, and that a section with nothing defensible returns empty rows plus a dataNote. It implies read-only behavior via 'fail-closed read models' but does not state permissions or rate limits — minor gaps for a read-only aggregation tool.

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

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

Every sentence earns its place: purpose and content are front-loaded first, behavioral disclosure second, and usage guidance last. The prose is dense yet not wasted, packing scope, calculation source, empty-result behavior, and invocation timing into three purposeful 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?

For a 0-parameter tool with no output schema and no annotations, this definition is complete. It specifies the data sources (same models as the terminal), the three content sections, the empty-result dataNote behavior, the compact JSON format, and the invocation timing. Nothing an agent needs to call it correctly is missing.

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

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

The tool has zero parameters and the schema coverage is 100%, so the baseline is 4. The description compensates for the missing output schema by detailing exactly what the returned data contains across its three sections, which is the closest analog to parameter/return semantics for a parameterless tool.

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

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

The description names a specific purpose — an aggregated 'one-call daily read' — and enumerates its exact contents: premium dislocations (with live-print vs frozen-oracle distinction), the forward corporate-action calendar, and Chainlink feeds that are not OK. This positions it as an aggregate digest distinct from granular siblings like chainlink_feed and pending_corporate_actions, making its scope unambiguous.

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

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

Explicit guidance is given: 'Call this first each session, and before any batch of trades placed via a trading MCP server.' This gives a clear and actionable when-to-use instruction. It does not name alternatives or state when not to use it, but the 'first-call' framing implicitly differentiates it from the granular siblings.

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

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

With no annotations, the description fully discloses key behavioral traits: precomputed every 5 minutes, has computedAt/validUntil fields, withheld with a dataNote past its ceiling, null handling for asset classes with no priced token (never a fabricated zero, with pricedTokens indicating backing), and the daily series having no freshness gate with missing days meaning the precompute never ran. This is exceptionally transparent for a zero-parameter tool.

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

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

The description is long but information-dense, with each sentence adding meaningful detail: purpose, data sources, refresh cadence, null policy, and freshness semantics. It is front-loaded with the core purpose before diving into technical specifics. While it could be tightened, no sentence is wasted or redundant.

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

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

For a zero-parameter tool with no output schema, the description covers all necessary context: what it computes, how often it refreshes, validity windows, edge cases (null classes, missing daily series), and the meaning of the data. An agent would have everything it needs to understand what the tool returns and how to interpret it.

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

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

The tool has zero parameters, and the schema is empty with 100% coverage. The baseline for 0-parameter tools is 4, and the description adds no parameter semantics because there are none to describe. The description still contributes by clarifying what data the tool returns, which is beyond parameter concerns.

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: reporting chain composition by asset class (stock/stable/memecoin/other) with on-chain value and holders, plus the daily RWA-share series. It frames it as the 'measured answer to equities chain or memecoin chain', which is specific and distinct from the sibling tools like chain_economics or get_chain_stats. The verb is implied (provides/reports) but the resource and scope are unambiguous.

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

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

The description implies usage for understanding the chain's composition and answering whether it's an equities or memecoin chain. It gives clear context on what the tool delivers (the measured answer), but does not explicitly contrast with alternatives or state when to avoid it. Sibling differentiation is not explicit, but the unique output makes the use case obvious.

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

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

With no annotations, the description carries the full burden and does so superbly. It discloses data sampling methods (sampledBlocks/totalBlocks), null vs. zero handling for fees, missing-hour semantics, the staleness flag, and explicitly labels the inferred revenue as a 'LABELLED ESTIMATE, never reported revenue.' This is exemplary behavioral disclosure.

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

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

The description is a single dense paragraph but every sentence adds substantive value—no filler. It could be slightly improved by breaking into bullets, but it remains efficient and well-ordered, front-loading the core purpose before diving into data-quality caveats.

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?

The tool has no output schema, so the description must convey return content and behavior. It does comprehensively: metrics list, sampling method, edge cases (null fees, missed hours, stale flag), and folded windows. An agent can confidently call this tool and interpret results without further documentation.

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 single parameter 'hours' is fully described in the schema (default 72, min 1, max 720), and the description adds no additional parameter nuance beyond the schema. Since schema coverage is 100%, the baseline of 3 is appropriate; the description doesn't need to repeat what the schema already provides.

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

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

The description clearly states the tool measures Robinhood Chain sequencer economics from blocks, listing specific metrics (transactions, gas used, L2 fees, contract deploys, ERC-4337 traffic). The scope is precise (hourly rollups, daily folds, labeled estimates) and distinct from the sibling tools, which are general stats or other chains.

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 doesn't explicitly name alternatives or when not to use this tool, but it strongly implies its use case: analyzing sequencer economics, fee breakdowns, and subsidy-cliff impacts. The rich detail on what it returns (e.g., 30d daily fold, stale flag) makes its applicability clear, though it stops short of explicit comparison with chain_composition or get_chain_stats.

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

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

With no annotations, the description fully compensates. It explains data freshness ('as the 5-minute oracle_health pass last saw it'), the cache-based nature, the oraclePaused flag being advisory and not enforced, and the behavior of returning feed: null when the snapshot is past ceiling. It also clarifies the cadence semantics, leaving no ambiguity about the tool's 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 description is lengthy but information-dense, with no filler. It front-loads the core function and then expands on edge cases and related data. The structure is a bit run-on, but every clause contributes to understanding the tool's output and caveats. It could be split into shorter sentences, but the flow is logical and 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 the tool's complexity (multiple output fields, several verdicts, null conditions, and a cross-reference to another tool), the description is thorough. It explains the return structure, the meaning of each verdict, the null handling, and the advisory nature of the paused flag. With no output schema, this description covers everything an agent needs to interpret results 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?

There is only one parameter, and its schema description already covers the three valid input types (symbol, token address, feed address). The description repeats this exact scope without adding extra constraints or format details. Since schema coverage is 100%, the description adds no additional semantic value beyond reinforcing the parameter's acceptable forms.

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 what the tool does: returns a Chainlink feed snapshot for a given ticker/address, including round data, oracle paused flag, deviations, and a verdict. It names specific fields and behaviors (e.g., feed: null on stale snapshot), making the purpose unambiguous and distinct from generic token queries.

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 context (when you need Chainlink feed data) but does not explicitly contrast with alternatives or state when not to use. It references 'rhxbt' as a separate tool carrying the premium board's read, but there is no direct guidance on choosing between them. Given the detailed scope, the intended use is clear, but exclusion criteria are absent.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It states 'Returns observed data only, never a buy/sell recommendation,' 'Unknown values are null, never fabricated,' and clarifies that 'unknown means not assessed, never clean.' It also details the exact data fields and their semantics, providing strong transparency about what the tool does and does not do.

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

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

The description is a single dense paragraph that packs a lot of information but remains logically structured: purpose first, then output details, then handling of unknown values. It is efficient, though it could be broken into bullet points for readability. It is not overly verbose and every sentence adds value.

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

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

Given the lack of an output schema and annotations, the description is thorough in explaining what data is returned, the meaning of each field, and the behavior for unknown values. It covers the main aspects an agent would need to call the tool correctly. Minor gaps remain, such as error handling for invalid symbols, but these are not critical.

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

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

Schema coverage is only 50% (trade_size_usd has a description, symbol_or_address does not). The description compensates by explaining what each parameter is for: 'by symbol or 0x address' for symbol_or_address and 'for exit-impact estimate' for trade_size_usd. This adds meaning beyond the schema, though it could be more explicit about the default value of trade_size_usd.

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

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

The description opens with a specific verb-resource pair ('Pre-trade risk readout for a Robinhood Chain token by symbol or 0x address'), which clearly states what the tool does. It also differentiates itself from siblings by emphasizing its pre-trade safety assessment role, contrasting with tools like get_token or get_launch_radar.

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 explicitly states when to use the tool: 'designed to be called BEFORE placing a trade elsewhere (e.g. via robinhood agentic trading).' This gives clear usage context. However, it does not mention when NOT to use it or name alternative tools, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden of disclosing behavior, and it does so thoroughly. It states that the current reading is withheld past a 'lending freshness ceiling' and the response says 'stale', while the settled series is always readable. It explains that APY is what borrowers pay, not a promise, and that the app's headline rate is not measured. It also notes that data is captured every 10 minutes, providing temporal granularity. These are concrete behavioral traits beyond any schema or 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?

The description is a single long sentence with many clauses, but it is well-structured with parentheticals and a colon, effectively organizing distinct pieces of information. Every phrase adds value: markets, aggregates, series, staleness, APY semantics, exclusions, and a disclaimer. It is dense but not verbose; it earn its place. A slight improvement could be breaking it into shorter sentences, but the current form is efficiently packed.

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?

The description covers a wide range: what markets are included, how the aggregate is computed, the series frequency, staleness behavior, the meaning of APY, and exclusions. It also mentions key fields like marketsWithoutApy and stockCollateralShare. However, it does not explicitly describe the response structure (e.g., whether the series is an array of timestamps and values), and it doesn't mention pagination or error cases. Given the complexity and lack of an output schema, it is quite complete but leaves minor gaps in the expected return format.

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

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

The tool has zero parameters, and the schema is an empty object with 100% coverage (meaning the schema is fully described, i.e., empty). Baseline for no parameters is 4. The description adds context about what the tool returns, which is more than necessary for parameters but helps set expectations for the output. Since there is no parameter semantics to clarify, the score aligns with the 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 clearly identifies the tool's subject (Robinhood Earn as observed on Morpho) and enumerates the data it provides (USDG-loan markets, aggregates, 7-day series). It is distinct from sibling tools by its specific scope, even though it lacks an explicit verb like 'retrieve' or 'show'. The description reads as a detailed specification rather than a tautology, so it exceeds a basic statement but stops short of the crispness of 'display Robinhood Earn data'.

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 Robinhood Earn data on Morpho, but it does not explicitly state when to choose this tool over siblings like get_lending_markets or get_stock_premiums. It does provide some exclusions: it notes the app's headline rate after vault fee is not measured, and that APY is not a promise, which helps an agent understand what the tool is not for. However, no alternative tools are named, so the guidance is implicit rather than explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a simple read statement by explaining valuation methodology ('valuation-clocked'), exclusion of unpriced rows with a flag, and the null-with-dataNote behavior instead of fabricated zeros. This is exemplary transparency for a read tool with no annotations.

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

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

The description is two sentences and front-loaded with the core purpose. However, the second sentence is dense and contains somewhat cryptic phrasing ('valuation-clocked', 'The one read no L2-only view can produce') that might reduce clarity. It is appropriately sized but could be streamlined for readability.

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

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

Given no output schema and no annotations, the description adequately explains return behavior for the tool's complexity. It mentions key output fields (netUsd, valuationCoverageComplete, dataNote) and handles edge cases. For a zero-parameter, read-only tool, this is complete and will guide an agent effectively.

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

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

The tool has zero parameters, so per the rubric baseline is 4. The schema is empty and additionalProperties is false, so there are no parameter semantics to explain. The description correctly omits parameter details, as none exist, and does not need to compensate.

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 a specific verb+resource: 'Net capital flow across the canonical L1 bridge over the last 24h'. It distinguishes from sibling tools by focusing on bridge flows specifically and adds a unique qualifier ('The one read no L2-only view can produce'). This is a precise, non-tautological statement.

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 provides clear context for when to use (to get bridge flow data) and hints at uniqueness, but it does not explicitly exclude alternatives or name specific sibling tools. The phrase 'The one read no L2-only view can produce' gives some differentiation but is not a direct usage guideline. No explicit when-not or alternative names are given.

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

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

No annotations provided, so description carries full burden. It mentions 'Latest' but lacks details on data freshness, refresh rate, safety, or side effects. The tool is likely read-only, but this is not confirmed.

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 sentence, front-loaded with key information, zero waste. Perfectly concise for the simplicity of the tool.

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

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

Given no output schema, description lists exact metrics returned. For a zero-parameter tool, this is reasonably complete, though a hint about data structure or units would enhance usability.

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 (baseline 4). Description adds meaning by listing the returned stats, which compensates for the lack of output 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 clearly states the tool provides 'Latest Robinhood Chain stats' and lists specific metrics (TVL, 24h DEX volume, stablecoin mcap, transactions, total addresses), distinguishing it from sibling tools that focus on individual tokens or risk analysis.

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 versus alternatives. For a zero-parameter tool, context is simple, but exclusions or comparisons to siblings like get_token or get_intel would improve clarity.

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

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

With no annotations provided, the description carries the full burden and discloses meaningful behavioral traits: data is 'computed from chain-timestamped logs' and 'tokens with no settlement in the window are omitted, never zero-filled'. These details go beyond a simple data summary and help set expectations for data completeness and source, which is valuable for a read-only tool.

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

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

The description is a single dense sentence but every clause contributes specific information about the metrics and behavior. It is not as tightly structured as a two-sentence summary, and the opening phrase 'the layer that exists nowhere else' is slightly promotional, but it avoids redundancy and stays focused on content.

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?

Despite having no output schema, the description covers the key return aspects: what metrics are included (offHoursPct, minted/burned shares, dvpVwapUsd), how they are computed, and the omission policy. It implicitly indicates a per-stock breakdown through 'per-stock settlement activity'. For a tool with a single parameter and relatively clear scope, this is sufficiently complete.

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

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

The input schema provides 100% coverage with a single parameter, `window`, including an enum and a description ('settlement window (default 24h)'). The tool description does not mention the parameter or add any additional nuance beyond what the schema already states, so the baseline 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 identifies the resource as 'per-stock settlement activity' and enumerates specific metrics (offHoursPct, minted/burned shares, dvpVwapUsd), making the tool's scope clear. However, it lacks an explicit verb like 'retrieves' or 'lists', instead using a noun phrase, which slightly reduces clarity. It does differentiate from siblings by emphasizing 'the layer that exists nowhere else'.

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 to use this tool by claiming its content 'exists nowhere else', suggesting it is the sole source for these settlement metrics. It does not name alternative tools or provide explicit when-to-use/when-not-to-use guidance, leaving the user to infer usage from the unique data claims.

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

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

No annotations provided. The description mentions 'Recent' and 'severity 1-5' but does not disclose caching, rate limits, real-time nature, or what happens with empty results. The parameter 'limit' implies pagination but is not discussed.

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 concise, using a single sentence with a list. It is front-loaded with the main purpose. However, it could benefit from slight restructuring (e.g., separating parameters).

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 2 simple parameters and no output schema, the description covers the core functionality adequately but lacks details on categories, output format, and pagination. It is minimally complete for a simple list 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?

The description adds minimal semantics: 'Optionally filter by category' indicates the category parameter is optional but does not list valid categories or explain the limit parameter beyond schema constraints. Schema coverage is 0%, so the description should compensate but does not.

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

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

The description clearly states that the tool retrieves recent intel signals, listing specific types (volume spikes, whale transfers, etc.) and mentioning severity and provenance. It distinguishes from sibling tools like check_token_risk or get_narratives by focusing on actionable 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?

No guidance on when to use this tool versus alternatives. It does not specify use cases, prerequisites, or situations where other tools would be more appropriate.

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?

Without annotations, the description carries the full burden. It explains ranking methodology (entry pricing, win condition, penalties for rug-shills, minimum calls) and includes the on-watch bench. Covers behavioral traits beyond a simple list.

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 dense sentence packs significant detail without redundancy. Could be split for readability but is not overly long. Every part is informative.

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

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

No output schema exists, yet the description does not specify return fields or structure. It mentions 'on-watch bench' but lacks detail on what each row contains. Incomplete for a data retrieval 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?

Only one parameter 'limit' with full schema coverage. The description adds no extra meaning beyond the schema's 'max rows (default 20)'. 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?

Explicitly states the tool returns a KOL leaderboard ranked by verified onchain call performance. Details like ranking criteria, win condition, penalties, and bench distinguish it from sibling tools like get_chain_stats or get_token.

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 to use (for leaderboard data) but does not explicitly state when not to use or mention alternatives. No comparison with siblings or exclusion scenarios.

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?

Despite no annotations, the description fully discloses behavioral traits: three-output assessment, safety score, liquidity, paid-promotion flag, and a critical caveat that a high score does not guarantee legitimacy. This adds significant transparency beyond structured fields.

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

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

Two sentences, front-loaded with key information. The first sentence covers purpose and output, the second adds an important caveat. No unnecessary 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?

Despite no output schema, the description explains the output structure and limitations. It covers the main aspects but lacks details on pagination or interpretation of the three-output gates. Adequate for a radar tool.

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

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

Schema coverage is 50% (limit has description; status has enum but no description). The description explains the output assessment but does not clarify the meaning of the status filter values (watching, clean, flagged) in input context. It adds some value but is not fully compensatory.

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 what the tool does: lists early-stage Robinhood Chain candidates from X chatter and onchain scans, with a three-output assessment. It distinguishes itself from siblings like check_token_risk and get_trending_tokens by focusing on early-stage candidates with specific evaluation criteria.

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 discovering early-stage candidates, and the sibling tools provide alternatives for detailed risk or trending. However, it does not explicitly state when not to use or provide direct comparisons.

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

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

With no annotations, the description carries the transparency burden. It discloses a non-obvious behavioral trait: freshness-gating, where outdated rows are withheld and the response says 'stale' rather than serving stale data. It also explains the meaning of stockCollateral, adding context beyond obvious read 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?

Two sentences, each dense with useful information. The first defines scope and data, the second explains an important behavioral constraint. No filler or repetition of schema details.

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?

The description covers the tool's purpose, key data fields, unique feature, and freshness behavior. With a single optional parameter and no output schema, this is more than sufficient for an agent to understand and invoke the tool correctly.

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

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

The schema already covers 100% of the parameter with a clear description. The tool description adds meaningful domain context by explaining that stockCollateral refers to registered tokenized equity, i.e., leverage against real stock, which is unique to this chain. This goes beyond the schema's phrasing.

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 returns Morpho lending markets on Robinhood Chain with specific data fields (supply/borrow USD, utilization, APYs) and highlights the unique stockCollateral feature. This distinguishes it from all sibling tools, none of which mention lending markets.

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 strong context for when to use this tool (when needing lending market data) and implicitly signals its unique value via stockCollateral. It doesn't explicitly name alternatives or exclusions, but the domain context is clear enough for an agent to select it appropriately.

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

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

The description fully discloses the output format (rankings, categories, clusters, labels, symbols) and implies no side effects or destructive actions. Since no annotations are provided, the description adequately informs the agent of the read-only nature.

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

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

The description is a single, well-structured sentence that conveys all necessary information without redundancy. Every element (ranked mindshare, static/dynamic, stability labels, member symbols) earns its place.

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

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

Given no parameters, no output schema, and no annotations, the description provides comprehensive information about the tool's purpose and return values, leaving no gaps for the agent.

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 zero parameters and 100% schema coverage, the description adds no additional parameter info, which is appropriate. The baseline of 4 applies as no further semantic clarification is needed.

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

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

The description specifies a verb ('ranked'), resource ('narratives'), and distinct output details ('static categories', 'dynamic clusters', 'stability labels', 'member symbols'), clearly distinguishing it from sibling tools like get_trending_tokens or get_token.

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 narrative analysis but does not explicitly state when to use this tool over alternatives such as check_token_risk or get_intel. The context is clear but lacks direct comparative guidance.

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

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

With no annotations, the description carries the full transparency burden and excels: it discloses the 10-minute precomputation cycle, the presence of computedAt, validUntil and a stale flag, and the critical behavior that stale rows are withheld rather than served. It also clarifies semantic nuances about counterparties and components, which are easily misinterpreted.

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

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

The description is a single, information-dense sentence that front-loads the main purpose ('stock-settlement counterparty graph') before filling in specifics. Every clause adds value—aggregation fields, staleness handling, and semantic disambiguation—without redundant or filler 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 the complexity of the graph tool, the description covers key aspects: what data is included, how it is aggregated, freshness, and semantic interpretation. It lacks explicit permission or rate-limit info (no annotations), but the absence of an output schema makes the detailed row-field listing more valuable. Slightly incomplete in operational details but strong overall.

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

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

The input schema has zero parameters, so there is no parameter semantics to explain. The baseline for 0 parameters is 4, and the description adds no unnecessary parameter details, instead focusing on the response structure, which is appropriate given the lack of an output 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 clearly identifies the tool as a stock-settlement counterparty graph, specifying the exact action (which wallets move tokenized equities to whom), the context (off-pool), and the aggregation details (per wallet with counterparty addresses, notional, concentration, etc.). This distinguishes it from sibling tools like get_equity_flows or get_bridge_flow, which focus on different data dimensions.

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 analyzing off-pool tokenized equity settlement relationships, but it does not explicitly state when to prefer this tool over alternatives or provide exclusions. Sibling tools are not referenced, leaving the agent to infer the niche from the detailed purpose statement.

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

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

With no annotations provided, the description carries the full burden. It explains the underlying detection mechanism (onchain transfer ratio at a specific block), clarifies that a change signifies a corporate action, and warns that it is not from an announcement feed. This goes beyond the tool name but does not cover potential edge cases like rate limits or data availability.

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 four sentences, each adding essential information. It front-loads the primary purpose and uses no filler words. It also earns its length by explaining the tool's unique relevance.

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 lack of output schema, the description adequately explains the return data (current value, previous value, and change time) and its significance. It could add details on data format or units, but the description is complete enough for an agent to invoke and interpret the result.

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

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

The tool has zero parameters, so the baseline is 4. The description adds meaningful context about what data is returned (current, previous, time of change) without needing to explain any parameters.

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

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

The description clearly states the tool retrieves the current ERC-8056 ui-multiplier per tokenized stock along with previous value and change time. It distinguishes itself from siblings by focusing on corporate actions (splits/dividends) and explicitly mentions pairing with the robinhood-chain-kit npm package.

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 a clear use case: 'Essential for interpreting historical prices and share counts across a split.' It also clarifies that the multiplier change is detected from onchain transfer ratio at a specific block, not from an announcement feed, which helps avoid misuse. However, it does not explicitly name alternative tools or when not to use this one.

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

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

With no annotations provided, the description carries the full burden and excels. It discloses data-source behaviors (live market only during regular session, oracle frozen at close), the semantics of premiumPct versus driftPct, and the envelope's own clock for session verdict. This is rich, non-obvious behavioral context.

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

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

The description is a compact paragraph of five sentences, each adding value: it introduces the three-way pricing, defines both metrics with caveats, and differentiates from siblings. No fluff; the most important facts are 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?

Given the absence of an output schema, the description effectively explains the return content: both metrics, the session verdict field, and the meaning of the values. It also provides enough context about data sources and timing to make the tool usable without further documentation.

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

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

The tool has zero parameters, so the baseline is 4 per rubric. The description adds no parameter information because none exists, but the input schema already confirms this. No deduction needed.

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

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

The description clearly states the tool returns pricing for tokenized stocks with three price sources (DEX, live market, oracle), and explains the key metrics premiumPct and driftPct. It explicitly differentiates from siblings by noting 'No other index on this chain has the live-market leg.'

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 explicit usage context: premiumPct is 'only meaningful while the session is open' and driftPct represents 'expected off-session drift, never an arbitrage claim.' This tells users when each metric is appropriate and warns against misinterpretation, while the sibling differentiation clarifies when to choose 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?

No annotations provided, so description carries full burden. It discloses the collision resolution policy (canonical Robinhood token wins) and lists the data returned. Missing details on error handling or rate limits, but still transparent about core 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?

Two sentences, front-loaded with purpose and contents, then collision handling. No wasted words. Efficient and clear.

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 output schema and moderate complexity, the description lists all key return components (snapshot, trend, intel, whale transfers) and handles collision. Missing possible error responses, but adequate for agent use.

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, the description adds critical meaning: it explains the format (symbol or hex address) and provides examples (TSLA, CASHCAT). This fully compensates for the schema gap.

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

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

The description uses a specific verb ('get full detail for one token') and resource ('by symbol or 0x address'), clearly stating the scope and content (snapshot, trend, intel, whale transfers). It differentiates from siblings by specifying it returns comprehensive data, unlike specialized tools like check_token_risk.

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 clearly indicates when to use (for comprehensive token detail), but does not explicitly exclude cases or mention alternatives like other sibling tools. However, the context of being a single-token lookup is clear.

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

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

With no annotations provided, the description carries the transparency burden. It discloses key behavioral details: supported intervals (5m, 1h, 1d), lookback limitations (up to 48h for 5m, full history for 1d), and that each bar includes a source field (dex/oracle). These details are beyond what the schema provides.

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 compact and front-loaded, containing only two sentences. The first sentence defines the core purpose, the second covers intervals/limitations and output detail (source). Every word adds value, with no redundancy or 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?

Given the tool's modest complexity (3 parameters, no output schema) and no annotations, the description sufficiently covers the purpose, data scope, and a key output attribute. However, it could be more explicit about the return format (e.g., array of candles) or default behavior for 1d with hours set, leaving some ambiguity.

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 description adds crucial meaning to the symbol_or_address parameter by stating it accepts a symbol or 0x address, which the schema does not describe. It also explains the relationship between hours and interval (e.g., 5m limited to 48h), supplementing the schema's generic descriptions and covering the 67% schema coverage gap.

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

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

The description clearly states that the tool returns OHLCV candles for one token, identified by symbol or 0x address, and specifies the intervals (5m, 1h, 1d) and lookback windows. This specific verb+resource+scope distinguishes it from siblings like get_token or search_tokens, which serve different data purposes.

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 clear context for when to use the tool: when OHLCV candle data for a token is needed, matching the terminal charts. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous given the sibling set contains no other candle 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?

No annotations provided, so description must carry the burden. It explains the scoring mechanism (z-scores vs 7d baseline) and lists returned fields (price, volume, holders, trajectory). This adds meaningful behavioral context beyond the input schema.

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

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

Two concise sentences front-loading the main purpose with no wasted words. Efficient and clear.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description adequately covers what it does and what it returns. Slightly incomplete in not explicitly stating descending ordering, but implied by 'ranked'.

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 only parameter (limit), so baseline is 3. Description does not add extra meaning for the parameter beyond what schema already provides, though it gives context about output fields.

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

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

Description clearly states the tool returns ranked trending tokens on Robinhood Chain by trendScore, which is a specific verb and resource. It distinguishes from sibling tools like get_launch_radar or get_token by focusing on trending status and the Robinhood Chain.

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 versus alternatives. Sibling tools exist but no comparisons or conditions are given.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it excels. It details the 15-minute refresh interval, the fail-closed behavior with calendarStale and dataNote, and explicitly states that no announcement feed is used (everything is read from contracts and the chain). It also mentions observedAt/observedBlock, giving a full picture of data provenance and staleness handling.

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

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

The description is a single dense paragraph, but it is well-structured: it starts with the core purpose, then explains the two modes, lists relevant fields, and concludes with behavior and failure handling. Each sentence adds unique value, and the information is front-loaded with the main verb and resource. It is not overly verbose given the complexity of the tool.

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

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

Since there is no output schema, the description must fully explain what the tool returns, and it does. It lists the data fields (current/pending multiplier, ratio, effectiveAt, secondsUntil, observedAt/observedBlock), explains the two directions, and details the stale behavior. For a tool with no parameters, this is exceptionally complete and leaves no critical ambiguity for an agent deciding to call it.

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

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

The tool has zero parameters, so the input schema is empty and schema coverage is trivially 100%. Per the rubric, a baseline of 4 is appropriate. The description does not need to explain parameters, but it adds useful context about the fields returned (newUIMultiplier, effectiveAt, ratio, etc.), which enriches the agent's understanding 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?

The description opens with a specific verb and resource: 'ERC-8056 corporate actions on tokenized stocks, both directions in time.' It clearly names the two modes (pending and log) and explains what each represents, distinguishing the tool from generic stock data tools. It is not a tautology and provides a precise, actionable definition.

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 clear context on when to use the pending mode (forward calendar of announced splits/dividends) versus the log mode (past transitions from transfer ratios). It does not explicitly mention alternative sibling tools like get_stock_multipliers, but it gives enough detail for an agent to infer the appropriate use case. No exclusions or when-not-to-use guidance is offered, but the dual-mode explanation is a strong usage guide.

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

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

With no annotations, the description carries the full behavioral burden. It discloses key traits: missing hours represent missed passes (never zero), settled hours are immutable (no freshness gate), future-dated buckets are refused, and ordering is newest first. This is substantial behavioral context beyond the schema. Lacks only explicit confirmation of the returned data shape but is strong otherwise.

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

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

Four sentences, each delivering distinct value: core function, resolution method, missing-data interpretation, and data-age/future behavior. No filler, well-organized, front-loaded with the primary purpose. Efficient and scannable.

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?

Despite no output schema or annotations, the description covers purpose, resolution, data quirks (missing hours, freshness), and order. For a two-parameter retrieval tool, it is nearly complete. The only minor gap is not explicitly stating the returned values (e.g., funding rate) beyond mentioning mark and index, but that is implied and not critical for correct invocation.

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% (both limit and market are described). The description repeats the resolution mechanism already in the schema ('Resolve by symbol (TSLA) or market id') and adds no new parameter-specific insight. Baseline 3 is appropriate as the schema fully documents parameters; description provides no extra semantic value for them.

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 ('funding series'), a specific resource ('one Lighter perp market'), and a clear scope ('hourly', 'newest first', 'mark and index'). It is clearly distinct from sibling tools like perps_markets (which likely lists markets) and other get_* tools, so an agent can identify its purpose without ambiguity.

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

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

The description implies usage for retrieving funding data and explains how to resolve a market (by symbol or id), but it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or preferred contexts. No sibling is named as an alternative for this specific need.

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

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

With no annotations provided, the description carries the full behavioral burden and largely meets it. It discloses freshness-gating ('rows older than ten minutes are withheld and the response says stale'), the regime logic (live vs drift vs none) with concrete definitions, and a disclaimed stance ('a basis is an observation, never a trade'). This goes beyond a typical tool description, though it omits return-format and pagination 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?

The description is front-loaded with the core purpose and key metrics, which helps. However, it is a single dense block containing intricate regime-definition prose and esoteric phrasing like 'a basis is an observation, never a trade,' which could be trimmed. Informative but not concise.

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 tool with no annotations and no output schema, the description must carry all load-bearing context, and it does: it specifies the per-market fields, the basis block contents, the regime meanings, and the staleness behavior. It is thorough given the tool's complexity, though it omits explicit return-structure and pagination details.

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 lone parameter (stocks_only) is already fully documented by the schema. The description adds complementary context by explaining that markets sharing a ticker with a registered tokenized stock carry the DEX spot price and basis block, reinforcing what stocks_only=true selects. This is a small increment over the schema baseline of 3.

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

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

The description states the tool lists perpetual markets on Robinhood Chain (the chain's native perp venue, USDG-quoted) and enumerates the returned metrics: mark, index, open interest, 24h volume, funding rate, settlement time, and, for stock-tickered markets, a basis block. It differentiates itself by claiming 'No other index has both legs,' which helps identify it against siblings. The verb is implicit rather than explicit, but the resource and scope are precise.

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 context through 'No other index has both legs,' suggesting this is the only venue to obtain both the DEX spot leg and the basis block. However, it never names alternatives such as the sibling perps_funding tool, nor does it state when NOT to use this tool in favor of another. Guidance is implied rather than explicit.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose the search types and expected return fields (price, change, holders, mcap, liquidity), but it omits details like whether it is strictly read-only, rate limits, or result sorting. The description is not misleading, but it leaves some behavioral aspects understated given the absence of annotations.

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

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

The description is a single, well-structured sentence that front-loads the action and resource. It includes the search scope and return fields without unnecessary fluff, making every word count.

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 output schema, the description appropriately lists the returned fields (live price, 24h change, holders, mcap, liquidity) and the search mechanism. It does not explain edge cases like zero results or exact matching behavior, but for a simple search tool with two parameters, it covers the essential contextual needs for an agent to decide invocation.

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

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

Schema coverage is only 50%, with 'query' lacking a schema description. The description compensates by explaining that the query can be a symbol, name, or address fragment. The 'limit' parameter is already described in the schema, so the description adds the necessary semantic meaning for the otherwise undocumented parameter.

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 verb 'Search' and the resource 'tokens on Robinhood Chain' with explicit search dimensions (symbol, name, 0x address fragment). It also distinguishes itself from sibling tools like get_token by indicating it returns search matches with multiple fields, making its purpose unambiguous.

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

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

The description gives clear context that this is the same search used in the terminal's popup, implying a general token search. However, it does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusions but still provides enough situational context.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses the data source (totalSupply() hourly), counting basis (at par), precomputation cadence (every 5 minutes), staleness handling (computedAt/validUntil, withholds rows with dataNote), null behavior for immature readings, and an explicit disclaimer ('Says nothing about peg'). This goes beyond typical descriptions.

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

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

The description is a single dense sentence but front-loads the core purpose and then lists the data returned. Every clause adds relevant information; however, the lack of paragraph breaks or bullet points makes it slightly harder to parse quickly. Minor structural weakness prevents 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?

Given the tool has no parameters, no output schema, and no annotations, the description is remarkably complete. It explains the data source, the exact list of returned fields, the refresh cadence, staleness semantics, null cases, and even a caveat about what it does not claim (peg). An agent has enough to call and interpret the tool correctly.

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

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

The tool has zero parameters and an empty schema, so by the rubric the baseline is 4. The description adds nothing parameter-specific (there is nothing to add), but it does not need to since there are no inputs.

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

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

The description states a specific verb ('read') and resource ('stablecoin float on Robinhood Chain') and enumerates the exact metrics returned (per-stable supply, share of float, changes, minted/burned totals, holders, deployed ratio, large mints/burns, gateway legs). This is precise and clearly distinguishes the tool from siblings like get_bridge_flow or chain_composition.

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 clearly conveys the scope (stablecoin data on Robinhood Chain) and the specific outputs, so an agent can infer when to use it (e.g., when needing stablecoin supply or flow metrics). However, it does not explicitly name alternative tools or state when NOT to use it, which prevents a 5.

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

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

With no annotations provided, the description carries the full burden and does so exceptionally. It discloses that data is precomputed every 5 minutes, the response includes computedAt and validUntil, stale data withholds rows with a dataNote instead of serving misleading info, and tokens with no flow in 30d are omitted (never zero-filled). These behavioral details go well beyond what a typical tool description provides.

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 information-dense yet concise. It opens with the core definition, then adds context about the AP/ETF use case and DEX exclusion, then covers data freshness and omission rules. Every sentence contributes meaningful detail, with no redundant or filler content. It is a single compact paragraph that front-loads the most critical 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?

Despite having no parameters and no output schema, the description fully equips an agent to understand what the tool returns: windowed aggregates (24h/7d/30d) with event counts, shares created/redeemed, netShares, and freshness metadata (computedAt/validUntil, dataNote). It also clarifies the conceptual foundation (primary-market vs DEX). Nothing essential for calling this tool correctly is missing.

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

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

The tool has zero parameters, so the baseline is 4. The description correctly does not attempt to add parameter documentation. It implicitly communicates that the tool requires no configuration, which is appropriate given the schema has no properties.

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 function: it reports primary-market creations (mints) and redemptions (burns) per tokenized stock over 24h, 7d, and 30d windows, with event counts, shares created/redeemed, and netShares. It also distinguishes itself from DEX indexes by explaining that primary-market flow never touches a pool, which differentiates it from sibling tools like get_stock_premiums or get_stock_multipliers.

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 clear context on when to use this tool: it is the authorized-participant read for an ETF desk and is not found in DEX indices. However, it does not explicitly name alternative sibling tools or state conditions like 'use X instead when you need secondary-market data.' The guidance is implied rather than explicit, so it's strong but not perfect.

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