Otto Data — Robinhood Chain

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is known. The description adds behavioral context by specifying the derivation from position_closed events, inclusion of a per-ticker breakdown, and the last 20 closed trades, which goes beyond the annotations. No contradiction with 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 compact, using two sentences to convey output metrics and parameter filtering. The first sentence is list-heavy but front-loaded with the core purpose. There is no repetition of trivial details, though the structure could be slightly clearer with bullet points.

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 lists the main returned metrics, which is essential. However, it omits the meaning of the days parameter, default behaviors, and any caveats about data freshness or limitations. For a simple read-only analytics tool, it is adequate but has clear 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?

The schema has 0% description coverage, leaving all three parameters undocumented. The description compensates well for agent and mode by explaining their allowed values, but entirely omits days, whose purpose as a lookback period is only inferred from its default value of 30. Thus partial compensation.

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 realized trading performance metrics for an agent, derived from position_closed events, listing specific outputs (trade count, win rate, P&L, holding hours, ticker breakdown, last 20 trades). This distinguishes it from sibling tools like gap_trade_signals or competition_my_portfolio by focusing on completed agent trades.

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 allowed values for agent (gap-trader | narrative-trader) and mode ('' | paper | live | onchain), implicitly telling users how to filter. However, it does not explicitly state when to use this tool versus alternative performance-related tools, nor mention any exclusions or prerequisites.

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

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

Annotations already declare read-only and idempotent hints; the description adds the event-counting rule, live Chainlink price join, and mode filter semantics. This enriches understanding beyond what annotations alone convey.

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 with the core concept, followed by parameter details. Every sentence contributes meaningful information without 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?

The derivation logic and P&L inclusion are clearly specified, but with no output schema, the return structure is not described (e.g., whether positions are aggregated, pagination, field list). It is adequate for basic use but not fully complete for complex expectations.

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 0%, but the description compensates by enumerating valid values for both parameters ('agent: gap-trader | narrative-trader', 'mode: '' | paper | live | onchain') and explaining mode's meaning. It does not mention defaults, though the schema provides those.

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 'server-side derived open position book' with precise derivation logic, making the resource unambiguous. It distinguishes from 'raw agent events' but does not explicitly compare to sibling tools or use an action verb like 'get' or 'list'.

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

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

It states 'Replaces rebuilding the book from raw agent events,' which implies when to use this tool versus an alternative. The agent and mode filters are listed with allowed values, providing clear context. It does not explicitly state exclusions, but the open-position definition implicitly sets boundaries.

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 label the tool as read-only, idempotent, and safe, lowering the bar. The description adds valuable context: full history since genesis and the tokens_only filter behavior. It does not mention performance implications or verified_only behavior, but still adds meaning beyond 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?

Two concise sentences, front-loaded with the core purpose, then a parameter clarification. No redundant 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?

The description is adequate for a read-only list tool with good annotations, but misses the verified_only parameter entirely and offers no hints about output shape or pagination. It covers the core purpose but has clear 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 coverage is 0%, so the description must explain parameters. It only explains tokens_only ('returns only new token contracts') and leaves verified_only and limit undefined. Since 2 of 3 parameters are not semantically described, the tool is insufficiently documented.

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 lists new contract deployments on Robinhood Chain, identifies the data source (Ottoscan), and covers full history since genesis. This distinguishes it from sibling tools like chain_stats or token_flows.

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: if you want new contract deployments on Robinhood Chain, this is the tool. However, there is no explicit mention of when to use this over siblings, nor any exclusions or alternative tool references.

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, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful context about the data source ('Ottoscan analytics') and the specific metrics returned, which goes beyond annotations, though it does not disclose details like pagination or exact response format. This is adequate but not rich.

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

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

The description is a single, concise sentence with no fluff, and the key subject is front-loaded. However, the line break and parenthetical are slightly awkward, and it could be more structured, but overall it is tight and readable.

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 tool, the description lists the output metrics but fails to explain the 'days' parameter's effect and does not distinguish from the sibling 'chain_deployments'. With no output schema, the description leaves gaps about what exactly the tool returns and how to parameterize it, making it incomplete for safe 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 description coverage is 0% and the only parameter 'days' is not explained in the description at all. The description mentions 'daily' stats but does not clarify that the 'days' parameter controls the time range, leaving the agent without essential semantic information for this 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 states it provides 'Robinhood Chain deployment statistics' and enumerates specific metrics (daily deploy/token counts, top deployers, total contract/verified counts), giving a clear idea of what it does. However, it lacks a verb and does not explicitly differentiate from the sibling 'chain_deployments', making it less sharp than a fully explicit purpose 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?

The description offers no guidance on when to use this tool versus alternatives like 'chain_deployments'. No exclusions, prerequisites, or comparison to sibling tools are provided, leaving the AI agent to infer usage 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 mark the tool as read-only, idempotent, and non-destructive. The description adds important context beyond annotations: no API key is required, and server-priced Chainlink fills prevent gaming, providing trust and access details not present in 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?

Three tightly packed sentences: a clear statement of what the tool returns, a note on access, and a note on data integrity. No redundant or filler wording.

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?

Even without an output schema, the description enumerates returned fields (equity, P&L, open position count, trade count, last activity) and explains the ranking basis. For a simple read-only list tool with one optional parameter, this is fully complete.

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

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

The schema has one optional 'limit' integer with default 25, but the description provides no parameter semantics (0% coverage). While 'limit' is intuitively the number of leaderboard entries, the description does not confirm this, leaving room for guesswork.

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 public leaderboard for Otto's paper trading competition, ranking participants by return % on the shared $10,000 starting budget. It distinguishes itself from sibling tools like competition_my_portfolio (personal portfolio) and competition_paper_trade (trading action).

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

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

It states 'No key required,' signaling open access, and describes the leaderboard's contents, making it clear this is the tool to use for public competition rankings. It does not explicitly contrast with alternatives or list exclusions, but the context is strong.

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 establish read-only, idempotent, non-destructive behavior. The description adds behavioral context by detailing the return payload: cash, equity, return %, P&L, open positions with live prices, and recent trades with source tags, plus strategy prefs. This goes beyond the annotations to explain what the user will see, but it doesn't cover auth failures, error handling, or rate limits. With annotations covering safety, a 3 is appropriate.

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 fluff. The first sentence is a dense list of contents, which is informative but somewhat long; the second is a practical usage directive. Structure is front-loaded and purposeful, earning a 4 rather than a 5 due to the heavy enumeration.

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 thoroughly enumerates the returned fields and explicitly positions the tool in its workflow ('Check this before sizing a new competition_paper_trade'). There is no output schema, so the description has the full burden of conveying return values, which it does well. It doesn't mention pagination or errors, but for a read-only portfolio query, this is acceptable.

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 only defines 'api_key' as a string with title 'Api Key' and no description (0% coverage). The description references the key companion 'behind an otto_pk_ key', adding that it identifies the portfolio. This gives some semantic meaning but doesn't explain the key's format, how to obtain it, or what happens with an invalid one. Since there is only one parameter, the description partially compensates but not fully.

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 defines the tool's resource as 'The competition paper portfolio behind an otto_pk_ key' and enumerates its contents, making it clear this is a read/query tool for portfolio data. It distinguishes from sibling 'competition_paper_trade' by referencing it as the action to precede. However, it lacks an imperative verb like 'Retrieve' or 'List', which slightly weakens purpose clarity.

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 explicitly directs when to use: 'Check this before sizing a new competition_paper_trade.' This is a clear usage context. It does not explicitly mention when not to use or alternatives like agent_position_book, but the 'competition' scope and otto_pk_ key provide context. Given the explicit check-before instruction, this is strong 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=false and destructiveHint=false, but the description goes well beyond them by explaining that no real funds move, prices are server-side and cannot be caller-supplied, rules are enforced server-side, and error responses are formatted as {"error": "..."}. It also clarifies the api_key purpose and that reason appears in trade history, offering rich behavioral context.

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

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

The description is long but every sentence adds distinct value: purpose, safety, pricing, parameter explanations, rules, and error handling. It is front-loaded with the core action and structured cleanly. No filler or 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?

The tool is moderately complex with no output schema, and the description covers key behavioral aspects: no real funds, server-side pricing, parameter meanings, and server-enforced rules. It even explains error responses. However, it does not describe the success response format or explicitly explain `ticker`, leaving a minor completeness 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 0%, so the description must compensate. It explains api_key (personal otto_pk_ key), side (buy | sell), qty (shares), and reason (shows in trade history). However, it omits the required `ticker` parameter entirely, which is a small but notable gap. The explanation of the other parameters adds meaningful value 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 clearly states the tool's purpose with a specific verb and resource: "Place a PAPER fill in Otto's trading competition on behalf of the key's owner." It also differentiates this from real trading by emphasizing "No real funds move" and that pricing is server-side. This makes it distinct from sibling tools like execute_onchain_swap.

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 that this is for paper trading in a competition, with rules such as $10,000 budget, long-only, max $2,000 notional, 10 positions, and 40 trades/day. It does not explicitly name alternative tools or state when not to use it, but the paper-trading context and explicit constraints provide sufficient guidance.

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

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

Beyond the annotations (destructiveHint, readOnlyHint false), the description adds critical real-world context: signing via server wallet, server-enforced guardrails (allowlisted pairs, USD caps, slippage cap), and automatic side effects (order_filled/position_closed events, position book updates). This fully discloses the consequences of calling the 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 front-loaded with the core purpose and packs essential operational details into four sentences. Every sentence adds value covering side semantics, guardrails, side effects, and return values, with no fluff or repetition.

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

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

Given the complexity (9 params, real-money mutation, multi-step effects), the description covers safety, auth, side effects, and return values, even without an output schema. It lacks error behavior and does not reference pre-swap quote workflow, but overall it is remarkably complete for such a high-stakes 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, the description compensates well by explaining key (OTTO_AGENT_KEY), side (buy vs sell semantics), usd_amount and qty roles, agent options, and slippage cap. However, reason and run_id are entirely unaddressed, and ticker is only implied, leaving a few gaps.

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 clear verb and resource: 'Execute a REAL on-chain swap on Robinhood Chain via the Rialto router'. It explicitly contrasts with paper trading ('REAL') and explains side=buy/side=sell semantics, making it unmistakably distinct from siblings like competition_paper_trade or partner_swap_quote.

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 context on when to use (agent: gap-trader | narrative-trader) and explicitly states that on success no separate report_agent_status call is needed. However, it does not explicitly mention alternatives like partner_swap_quote for pre-trade quotes, so it stops short of a full when/when-not 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by enumerating the output metrics and clarifying mint/burn as supply change, which goes beyond the annotations. However, it lacks limitations or data source details.

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 sentence, front-loaded with the tool's purpose, and efficiently lists the key metrics. There is no superfluous content, making it highly concise and well-structured.

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

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

The tool is simple with one optional parameter and no output schema, and safety is covered by annotations. However, the description omits the meaning of the 'hours' parameter and does not differentiate from the sibling 'token_flows', leaving ambiguity in usage. It is adequate but has clear 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?

The single 'hours' parameter has zero schema description coverage and is not mentioned in the tool description. The parameter name 'Hours' and default 24 give a hint, but the description fails to explain its meaning (e.g., lookback period), so the description does not compensate for the low schema coverage.

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 a whale-flow summary per ticker with specific metrics (transfer count, total USD volume, mint/burn USD, largest transfer). However, it doesn't distinguish from the sibling tool 'token_flows', which likely performs a similar function, preventing 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?

The description implies the tool is for whale-flow summaries per ticker but provides no explicit guidance on when to use it versus alternatives like 'token_flows'. There are no exclusions or prerequisites mentioned, so usage is implied rather than clearly directed.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is known to be a safe, read-only, idempotent operation. The description adds valuable behavioral context beyond the annotations: it labels the outputs as 'deterministic,' describes the per-ticker data included, and explicitly warns 'Signals are NOT orders,' which helps prevent misuse. This exceeds the baseline expected when annotations are present, though it could still mention behavior like absence of results or pagination.

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 yet information-dense. It front-loads the core purpose, then lists the output fields with explanations, and ends with a parameter filter and a safety note. Every sentence adds value; there is no filler or repetition. Despite being a single long sentence for the outputs, it is well-structured with em-dash separators and remains readable.

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 read-only tool with one optional parameter and no output schema, the description provides a complete picture: it explains what the tool returns (per-ticker funding rate, APR, basis gap, carry label, risk flags), how to filter the results, and that signals are not orders. It does not require a return schema because the output fields are explicitly described. The only minor omission is the exact composition of 'standard risk flags,' but this likely follows the platform-wide convention and is not a critical 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?

The input schema only provides the parameter name, type, and default (min_abs_bps: number, default 0), with no description. The tool description directly explains the parameter's purpose: 'min_abs_bps filters on |perp_vs_chainlink_bps|.' This fully compensates for the 0% schema description coverage, giving the agent clear guidance on how to use the 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 specifies exactly what the tool produces: deterministic funding-carry candidates that combine perp funding rates with perp-vs-spot basis. It details the output fields (funding rate, funding APR, basis gap, carry label) and clearly distinguishes from order execution with 'Signals are NOT orders.' This goes beyond a simple verb+resource and effectively differentiates from sibling tools like perp_funding and perp_spot_basis by describing the combined 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?

The description clearly implies when to use this tool: when you need deterministic funding-carry candidates that merge perp funding and basis data. It also states what it is not (orders), which helps avoid misuse. However, it does not explicitly name alternative tools or state exclusions, so it falls short of the 'explicit when/when-not/alternatives' bar for 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?

Beyond annotations (readOnly, idempotent, non-destructive), the description adds key behaviors: determinism, non-execution, suppression during regular session, and the pre-open window. This provides substantial context for what the tool does and its temporal constraints, with 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 compact, front-loaded with the core purpose, and each clause adds distinct information. It lists outputs, clarifies non-execution, and provides timing guidance without unnecessary 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?

The description enumerates many output fields and behavioral constraints, which is good given no output schema. However, parameter semantics for days and min_abs_bps remain under-specified, so the description is not fully complete for the two parameters.

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 must explain parameters. It mentions bps and 14-day statistics, but does not explicitly state that 'days' controls the lookback period or that 'min_abs_bps' sets a signal threshold. This leaves the meaning of the two parameters ambiguous.

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 provides deterministic signals for the gap-trader strategy, enumerating outputs (overnight gap, signal type, 14-day stats, hit rate, risk flags). It distinguishes from sibling tools by emphasizing that signals are NOT orders and by noting suppression during regular market hours.

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 specifies the most informative window (pre-open 09:15-09:29 ET) and that signals are suppressed during regular hours, giving clear timing context. It also states signals are not orders, guiding users not to expect execution. No explicit alternative tools are named, but the context sufficiently implies when to use.

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 read-only, idempotent, and non-destructive behavior. The description adds beyond annotations by disclosing that fan-out (same post, many tickers) is deduplicated and notes the basis is 'live,' providing freshness context. This is useful behavioral detail not present in structured fields.

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

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

The description is two sentences long, front-loaded with the core action, and contains no redundant information. Every sentence provides unique value: purpose in the first, deduplication behavior in the second.

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 read-only tool with one optional parameter, the description covers the main purpose and key behavioral nuance (deduplication). It doesn't describe the exact return format, but given the absence of an output schema and the straightforward nature of the tool, it is sufficiently complete for an agent to understand when and how to invoke 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 only parameter, min_alpha, has no schema description, and the tool description does not mention it or explain its meaning, units, or effect. The title 'Min Alpha' and the phrase 'alpha score' give a vague hint, but the description fails to compensate for the 0% schema description coverage, leaving parameter semantics mostly undefined.

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 joins Reddit attention/alpha with live basis for Hood tokenized stocks, identifying tokens with both social interest and on-chain premium/discount. It includes specific details like fan-out deduplication, distinguishing it from sibling tools such as reddit_alpha_signals or hood_basis_snapshot.

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 for when to use this tool: when you need to find tokens with simultaneous social interest and basis premium/discount. It doesn't explicitly exclude alternatives or name them, but the unique value proposition implies the appropriate use case.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. Description adds behavioral details: minute-level granularity, newest-first ordering, and a limit maximum of 5000. However, it does not describe time range, pagination, or error behavior, so the addition is moderate.

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 includes only essential details (examples and limit cap). No wasted words or 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 simple query tool with two params and annotations present, the description covers purpose, granularity, ordering, examples, and limit ceiling. It does not mention related tools or return format, but the output schema is absent and the tool's simplicity makes this sufficient.

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 0%, so the description must compensate. It provides example tickers (NVDA, TSLA, SPY) for the ticker parameter and a maximum for limit, giving practical meaning. It does not explicitly state limit's units or default beyond the schema's default of 200, but the examples and max constraint add value.

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: retrieving minute-level basis history for a single ticker, with ordering specified as newest first. It distinguishes from siblings like hood_basis_snapshot by explicitly saying 'history' rather than a current snapshot.

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 word 'history' and example tickers, but there is no explicit guidance on when to use this tool versus alternatives like hood_basis_snapshot or perp_spot_basis. No exclusions or alternative recommendations are provided.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds useful field-level semantics, such as the meaning of basis_bps sign and the oracle_paused flag, which goes beyond the minimal 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?

The description is a single, dense sentence that front-loads the core purpose and then lists the output fields efficiently. Every word adds value with no filler or repetition.

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

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

With no parameters and no output schema, the description fully specifies the tool's behavior by enumerating all returned fields and their meanings. It is complete for a simple snapshot 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?

This tool takes zero parameters, so the schema coverage is trivially 100%. The description does not need to explain parameters, but it does provide helpful context about what data is returned, which is sufficient for a no-argument 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 clearly identifies the resource ('all Robinhood Chain tokenized stocks') and the action ('basis snapshot'), with a specific verb 'snapshot' that distinguishes it from history tools. It also lists the key fields, leaving no ambiguity about what is returned.

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

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

The phrase 'Current ... snapshot' clearly indicates this is for present-time data, implicitly contrasting with hood_basis_history for historical views. It does not explicitly name alternatives but provides enough context to infer when to use it.

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 idempotentHint=true, so the description doesn't need to restate that. It adds behavioral insight about NASDAQ closed-market gaps and the 'live basis join' enrichment, which goes beyond static 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 compact and front-loaded with the tool's core purpose and key output fields. The additional risk warning and tickers instruction earn their place, though the sentence structure is slightly dense.

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 main output fields and risk context, making it useful for selecting the tool, but it leaves the days_ahead parameter undocumented and does not describe the return container (e.g., list vs single object). Given no output schema, this is a moderate 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?

The description explains the tickers parameter ('CSV filter (empty = full Hood universe)') but says nothing about days_ahead, which defaults to 30. This is a significant gap given 0% schema description coverage.

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 provides earnings risk for Hood tokenized stocks, listing specific output fields like implied_move_pct and beat_probability. It is distinguishable from sibling tools via the 'weekly earnings radar' and 'live basis join' terminology. However, it omits an explicit action verb (e.g., 'get' or 'list'), making it slightly less direct than ideal.

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

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

It gives a concrete use case—'watch small days_to_earnings for off-hours risk management'—and explains the tickers CSV filter behavior. It does not mention any sibling alternatives or explicitly state when not to use this tool, relying instead on 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that this is a registry of all feeds with specific address types, which goes beyond what annotations provide. It doesn't include caveats like data size or update frequency, but for a simple registry this is acceptable.

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, concise sentence that front-loads the core idea ('Registry of all...') and provides all necessary information without waste. Every word earns its place.

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

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

For a zero-parameter registry tool, this description is complete. It states exactly what the tool provides (all tokenized feeds and their contract addresses), and annotations cover the safety profile. No output schema is needed, as the content is clearly described.

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% (trivially). Per guidelines, the baseline for 0 parameters is 4. No additional parameter semantics are needed.

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

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

The description uses a specific noun ('Registry') and clearly defines the tool as a listing of all tokenized stock and crypto feeds on Robinhood Chain, specifying the exact content (Chainlink proxy + token contract addresses). This distinguishes it from sibling tools like hood_quote or hood_pools, which serve different 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?

No explicit when-to-use vs alternatives is stated, but the description clearly indicates this is the source for feed registry addresses. An agent can infer it's for looking up feed addresses, but it doesn't mention exclusions or alternate tools for comparison.

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 the tool read-only, non-destructive, and idempotent. The description adds behavioral context by specifying the output row structure—each overnight/weekend session is a separate row—and the per-ticker scope, which is not captured in the annotations.

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

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

The entire description is a single, well-structured sentence. It front-loads the core concept ('session-by-session gap history') and uses a parenthetical to clarify row granularity without 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 the minimal schema and no output schema, the description provides a strong conceptual model of what the tool returns (gap history per session). However, it omits the role of the 'days' parameter and the precise definition of 'gap,' leaving some ambiguity for an agent invoking the tool with non-default options.

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 0%, and while the description indicates the tool operates on 'one ticker,' it does not explain the meaning or effect of the 'days' parameter. The default of 14 is present in the schema, but the description offers no guidance on how days influences the result.

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

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

The description clearly identifies the tool as providing session-by-session gap history for a single ticker, with a parenthetical explaining that overnight/weekend sessions appear as separate rows. This distinguishes it from related tools like hood_gaps_summary and hood_gaps_live by emphasizing the historical per-session granularity.

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 historical use ('history') but does not explicitly state when to choose this tool over alternatives such as hood_gaps_live or hood_gaps_summary. No exclusion criteria or alternative comparisons are provided.

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

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

Annotations already declare read-only and idempotent, so safety is covered. The description adds valuable behavioral context: it returns 'regular' when the market is open, and it focuses on off-hours session data. This goes beyond the annotation hints.

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 concise sentences, front-loaded with the main purpose ('Live view of the current off-hours session') and includes necessary detail about the return value condition. 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?

For a simple zero-parameter tool with no output schema, the description is complete. It tells the user what data is shown (tickers with largest premium/discount) and the behavior during market open ('regular'). No significant 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?

The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameter semantics, and it doesn't. Schema coverage is 100% by default since there are 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: 'Live view of the current off-hours session' showing tickers with largest premium/discount vs last close. It distinguishes itself from siblings like hood_gap_sessions (likely historical) and hood_gaps_summary (likely summary) by emphasizing 'live' and 'current'.

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: this is for the current off-hours session, and when the market is open it returns 'regular'. This implies it should be used only during off-hours for live gap data. It doesn't explicitly name alternatives but the context is sufficient to differentiate from sibling 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds value by explaining what the statistics measure (premium/discount drift) and the specific metrics included, which goes beyond the annotation metadata. 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 all essential information front-loaded. The first sentence states the resource and metrics; the second explains the rationale. No fluff, perfectly sized.

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 is simple (one optional parameter, no output schema), and the description explains the purpose well. However, it lacks any explanation of the 'days' parameter's semantics or the expected return format. Given the complexity is low, this is a moderate 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?

The schema has one parameter 'days' with a default but no description, and schema_description_coverage is 0%. The description never mentions the 'days' parameter or how it affects the results, providing no guidance on what values are appropriate or what the default means. For a single-parameter tool, this is a significant 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 the tool provides overnight/weekend gap statistics (average, min/max, latest bps) for all tickers, with the specific context that it measures drift while NASDAQ is closed. It does not explicitly name sibling tools for differentiation, so it loses a point for not directly distinguishing from hood_gaps_live or hood_gap_sessions.

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 this is for summary-level gap statistics across all tickers, and gives context about 24/5 trading. However, it offers no explicit guidance on when to use this tool versus alternative gap tools such as hood_gaps_live or hood_gap_sessions, and no exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds behavioral context beyond annotations: the data is 'flattened from all research cards' and 'sorted by date,' indicating aggregation and ordering. It also notes the catalysts 'can move token prices,' which gives insight into the data's significance.

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 only two sentences, front-loads the core purpose in the first sentence, and adds the use case in the second. Every phrase earns its place: 'Dated catalysts that can move token prices while NASDAQ is closed' is immediately informative, and the audience guidance is 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?

Given that this is a zero-parameter, read-only list tool with no output schema, the description is remarkably complete. It specifies the content (dated catalysts), the timing (off-hours), the aggregation source (all research cards), the sort order (by date), and the intended use case. This is sufficient for a tool of this simplicity.

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 parameter semantics are moot. The description does not mislead about inputs, and the empty schema is consistent. Baseline 4 applies for a 0-parameter 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 clearly identifies the tool as a list of dated catalysts that affect token prices during off-hours (NASDAQ closed). It distinguishes itself from sibling tools by specifying the niche focus on overnight and weekend risk, and the phrase 'flattened from all research cards' implies an aggregated view.

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 explicitly states when to use it ('For agents watching overnight gap and weekend risk') and the temporal context ('while NASDAQ is closed'). It does not explicitly name alternatives or exclusions, so it stops short of a 5, but the intended use case 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?

Annotations already declare read-only and idempotent behavior. The description adds useful context beyond that: the refresh cadence (every 5 min) and the specific data fields (dev_bps vs Chainlink). This enriches the behavioral model without repeating 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?

A single sentence that front-loads the main subject and then enumerates the key contents. Every phrase 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?

For a read-only tool with no parameters and no output schema, the description covers the essential elements: the data scope, the metrics provided, and the freshness. It could mention return structure, but that is not critical for a simple list-type 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?

There are zero parameters, so the description is not required to explain arguments. The baseline of 4 for no-parameter tools applies, and the description does not mislead about 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 clearly identifies the resource (Uniswap pools) and the data provided (price per token, liquidity USD, deviation vs Chainlink). It does not explicitly contrast with sibling tools like oracle_deviation, but the specific data fields make the purpose clear.

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 is given about when to use this tool versus alternatives. The refresh note implies a snapshot use case, but there are no explicit exclusions or comparisons with sibling 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 declare readOnly, idempotent, non-destructive behavior. The description adds valuable context beyond annotations by stating the tool is 'minimal fast' and specifying the dynamic selection of 'the most liquid pool' plus the inclusion of oracle_paused/stale flags. No contradictions with 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 front-loaded with the core purpose in the first phrase, followed by a compact list of return fields. Two sentences only, with no filler or redundancy. Every word contributes.

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 one parameter and no output schema, the description covers the essential ground: input (ticker), return fields, and use case. It lacks fine-grained error handling or formatting details, but for a simple quote tool, it is sufficiently complete for an AI agent to invoke 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?

With 0% schema description coverage, the description must compensate. It implies the 'ticker' parameter refers to a Hood ticker (from 'one Hood ticker'), which adds some meaning. However, it does not provide examples, format expectations, or valid ticker values, leaving a partial 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 the tool provides a 'Minimal fast quote for one Hood ticker' and enumerates the specific data returned (Chainlink price, NASDAQ references, basis bps, pool price/liquidity/deviation, oracle flags). It distinguishes from siblings by explicitly noting it's for a single ticker and contrasts with the full 32-ticker snapshot.

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 usage guidance is provided: 'Use for sizing and fill pricing instead of pulling the full 32-ticker snapshot.' This tells the agent when to use it and identifies the alternative (full snapshot), making the decision 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 annotations already declaring read-only, idempotent, and non-destructive, the description adds substantial behavioral context: it is an API-only tracker refreshed every 3 hours, describes output components (regime, sector score/label, flow trend, theme matches, live basis), and explains ticker filtering behavior. This goes well beyond 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?

Despite dense content, the description is well-structured and front-loaded with purpose. It uses colons and em-dashes to organize output components efficiently, and every clause adds value without 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?

Without an output schema, the description fully communicates the return values: market regime, sector score/label/flow board, per-ticker join details (score, label, flow trend, theme matches, live basis). It also covers parameter behavior and data freshness, making it complete for a read-only lookup 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 schema describes only the 'tickers' parameter with no description (0% coverage). The description compensates by explicitly explaining 'tickers: CSV filter (empty = full Hood universe)', giving complete semantic meaning for the sole 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 identifies the tool as providing sector rotation context for Hood tokenized stocks, including market regime, SPDR sector scores/flows, and per-ticker sector join. It distinguishes itself from sibling tools by focusing specifically on sector rotation and money flow, answering 'where money is rotating'.

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 this tool ('Answers where money is rotating and whether your token's sector is in inflow or outflow'), providing context for use cases. However, it does not explicitly name alternative tools or exclude scenarios, stopping 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?

Annotations already define readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds meaningful behavioral context: the output fields, the api_data precision caveat ('use it when precision matters'), the handling of empty vs. provided ticker, and sourced catalyst data (off_hours-flagged, verified earnings dates). This goes well beyond the annotation safety profile.

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 with no filler: every clause adds specifics (ratings, columns, tags, api_data, mode). It is well front-loaded with the primary purpose. However, it lists five analysis columns while claiming '4 analysis columns', a minor structural inconsistency, and the single paragraph could benefit from light segmentation.

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 there is no output schema, the description carries full responsibility for explaining what the tool returns. It does so comprehensively: rating scale, column details, api_data fields, tag conventions, and the two modes (with/without ticker). It even notes when to favor api_data over derived numbers, making it highly complete for a research-report 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 single parameter 'ticker' has 0% schema description coverage. The description fully compensates by explaining the behavioral difference: with a ticker it returns 'one card + live basis join', empty returns 'full report'. This is critical semantics not available in the schema, though it stops short of giving examples or ticker format guidance.

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 produces a 'Daily deep-research report' with a specific rating scale (0-100 score, strong_buy|buy|hold|avoid) and detailed analysis columns (thesis, catalysts, financials, competitors, news_summary). It distinguishes itself from sibling tools like hood_quote or hood_ticker_brief by emphasizing in-depth research output and per-ticker or full-report behavior.

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 concrete usage context: 'With ticker: one card + live basis join; empty: full report.' It implies this is the deep-research tool, but it does not explicitly name alternatives or exclusions. Context is clear, but a reference to lighter-weight tools would earn 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds meaningful behavioral context by disclosing fail-soft behavior: 'Missing upstream sources fail-soft: the field is null.' This goes beyond the annotations and helps the agent handle missing data. No contradiction with 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 moderately long but earns its length by listing all components. It is front-loaded with 'One-call brief' and compresses the list into a readable comma-separated enumeration. The final sentence about fail-soft is concise. No fluff or redundant phrasing.

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 is complex with many distinct data points, and the description accounts for all of them: quote, research, earnings, sector rotation, Reddit attention, whale-flow, and news. It also explains the replacement value and the fail-soft behavior. No output schema exists, so the description carries the full burden of describing returns, and it does so sufficiently.

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 0%, so the description must compensate for the single 'ticker' parameter. It clarifies that it's a single 'Hood ticker' and implies a ticker symbol, but it does not specify format, case, or valid values. Given there is only one parameter, some guidance is provided, but more could be added (e.g., 'e.g., HOOD').

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 ('brief') and clearly scopes to a single Hood ticker, enumerating the exact contents (live quote, research card, earnings risk, sector rotation, Reddit attention, whale-flow, news). It explicitly distinguishes itself from siblings by stating it 'Replaces 6-7 separate tool calls,' making its purpose unmistakable.

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: use when 'an agent researches one ticker' and that it consolidates multiple otherwise separate calls. It does not explicitly state when not to use it (e.g., when a deep dive on one specific component is needed), but the context is strong enough to guide selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful details like event_type values and importance scale (0-100), but does not mention output format, pagination, or limit behavior. This adds some value beyond annotations but is not rich.

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

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

The description is a single, information-dense sentence. It front-loads the core purpose and packs in parameter formats and value ranges without wasteful prose. Every element contributes to usage understanding.

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 read-only list tool, the description covers the essential invocation details: symbols, event types, and importance scale. It lacks information about the response structure (which is machine-readable but undefined) and the effect of limit, but the schema provides defaults. Given annotations handle safety, this is fairly complete.

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

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

Schema description coverage is 0%, but the description compensates by explaining symbols (comma-separated with examples), event_type (full enumeration), and importance (0-100). It does not explicitly explain 'limit' or 'min_importance', though their names are self-explanatory. Coverage of 3 out of 4 parameters is strong.

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 provides 'Machine-readable news events (crypto + stocks)', which clearly identifies its purpose and scope. It distinguishes from siblings by focusing on news events, but the phrasing is a noun phrase rather than a specific verb like 'get' or 'list', so it's slightly less direct.

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 no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or comparison to sibling tools like hood_feeds or reddit_alpha_signals. The context is implied by the domain but not clearly articulated.

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, idempotentHint, and destructiveHint=false. The description adds meaningful behavioral context beyond annotations: it is 'deterministic,' the output is a candidate signal (not an order), and it clarifies the meaning of the signal bias field with an enum-like breakdown. It also notes the 'reason' field should be propagated. No contradictions with 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 dense but well-structured, using lists and em dashes to separate the key output components. The three sentences each carry useful information: what the tool returns, how to use the 'reason' field, and the non-order warning. It is appropriately sized for the complexity of the tool, though slightly long due to the detailed bias enum.

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 partially covers return values by listing alpha_score, evidence, themes, bias, Chainlink price, basis, and risk flags, plus the reason field guidance. However, it does not specify the exact return structure (e.g., list vs. object, key names), nor does it explain the 'basis' and 'risk flags' details. The missing parameter semantics further reduce completeness.

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 has 0% description coverage for its two parameters (hours, min_alpha), and the description does not mention either parameter or explain their purpose. The description is entirely silent on how hours and min_alpha affect the output, leaving the agent with only parameter names and defaults. This is a critical gap since the schema itself provides no semantic help.

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 'deterministic candidates for the narrative-trader strategy' and enumerates the key outputs (highest-alpha Reddit signal, bias, Chainlink price, basis, risk flags). It distinguishes itself from siblings like reddit_alpha_signals by focusing on the narrative-trader strategy and specifying 'per Hood ticker the highest-alpha Reddit signal.' However, it does not explicitly name or contrast with related signal tools, so it stops 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?

The description implies usage context: it is for the narrative-trader strategy and instructs to 'carry it into status reports and the chart as the buy/sell rationale.' It also warns that 'Signals are NOT orders,' which guides against misuse. However, it lacks explicit when-to-use vs. alternatives or exclusions, such as when to prefer reddit_alpha_signals or gap_trade_signals instead.

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 idempotentHint=true, so the safety profile is covered. The description adds meaningful behavior context: status categories and the note that large deviations are normal in low-liquidity pools, plus a hint to check liquidity_usd. 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?

The description is two sentences and immediately states the core metric and scope. The status thresholds and liquidity caveat are valuable additional context with 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?

For a simple read-only tool with one optional parameter and no output schema, the description covers the main output fields (status, liquidity_usd) and sorting. However, it fails to explain the min_abs_bps parameter or the full return structure, so the agent has incomplete information for correct invocation and result interpretation.

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 has 0% description coverage and the description does not mention min_abs_bps at all. The parameter name is somewhat suggestive of a minimum absolute basis point filter, but the description does not explain how to use it or its effect on results, so the agent is left guessing despite the descriptive name.

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 metric (Chainlink-vs-Uniswap pool price deviation in bps) and its sorting order. It distinguishes from other pool and position tools in the sibling list, though it lacks an explicit verb like 'get' or 'list'.

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 no explicit when-to-use guidance or alternatives, but it does provide interpretation thresholds (ok/warning/alert) and a caveat about low-liquidity pools, which helps the agent decide how to act on results. This is implied usage context rather than explicit 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, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds scope ('fills you've reported') and ordering ('most recent first'), which is useful but limited. It does not disclose pagination behavior, limits, or return format, but this is a simple read operation.

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 one short sentence that is front-loaded with the key action and resource. Every word earns its place, and there is no redundancy or fluff.

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 is a simple list with strong annotations covering safety. The description provides the essential scope and ordering. While there is no output schema and the description does not specify return fields, for a straightforward list tool this is sufficient. It slightly misses the opportunity to mention the limit parameter or response contents, but overall is complete enough.

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 0% and the description does not mention the parameters at all. The limit and api_key parameters are left entirely to the schema's basic type/default info. Since the description must compensate for the missing details and fails to do so, the parameter guidance is inadequate.

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 lists 'Recent fills you've reported with partner_report_fill, most recent first.' This identifies the specific verb (list/recent fills), the resource (your own reported fills), and distinguishes it from the sibling tool partner_report_fill which is the write counterpart.

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 implicitly conveys when to use this tool: to view fills you previously reported via partner_report_fill. It clearly connects to the reporting tool, but it does not explicitly state exclusions or alternatives (e.g., 'use partner_report_fill to submit new fills'). The context is clear enough for selecting between the read and write pair.

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 adds significant behavioral context beyond the annotations: it discloses that Otto trusts the partner without on-chain verification, which is a critical trust model detail. The annotations are all false and provide no meaningful transparency, so the description carries the burden and mostly fulfills it by explaining the trust assumption and the act of reporting to records.

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, getting straight to the point with the action and key parameters. The format is efficient, but the first sentence is slightly dense with parenthetical references. Overall, it earns its place with no filler.

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

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

Given 8 parameters, no output schema, and minimal annotations, the description is incomplete. It does not explain what response to expect, whether the report can be overwritten, what happens if the same tx_hash is reported twice, or how qty/usd/price relate to the fill. The trust model is disclosed, but other essential operational details are 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 description explains 'side' and 'tx_hash', but the input schema has 8 parameters total, and the description does not cover qty, usd, price, reason, ticker, or api_key. The schema itself has no descriptions (coverage 0%), so the description needed to compensate but only covers 25% of the parameters. This leaves significant ambiguity for the agent on how to populate the other 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?

The description clearly states a specific action: reporting a fill that was already signed and broadcast via partner_swap_quote, so it appears in Otto's records. It distinguishes itself from the sibling partner_swap_quote tool by explicitly referencing that tool and clarifying this is the follow-up reporting step.

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 context on when to use this tool: after the user has already signed and broadcast a transaction themselves via partner_swap_quote. It also warns that Otto does not verify the transaction on-chain, which is important for setting expectations. However, it does not explicitly list alternative tools or scenarios where another tool would be preferred.

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

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

Beyond the readOnlyHint annotation, the description adds crucial operational details: Otto never sees or holds the private key, never submits on the user's behalf, and describes the api_key issuance. It thoroughly explains the tool's safety boundary and execution model.

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

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

The description is dense but well-structured, using dashes to delineate parameters and key actions. Every sentence adds value, balancing detail with 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?

It specifies the exact return fields needed to build and sign the transaction (tx.to, tx.data, tx.value, min_buy_amount) and explains the self-execution flow. For a read-only quote tool with no output schema, this is comprehensive and leaves minimal 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?

With 0% schema description coverage, the description compensates by explaining api_key, sell_token/buy_token as contract addresses, sell_amount in human units (e.g., '25' USDG), and taker as the signing wallet. However, it omits slippage_bps, which is only present in the schema with a default.

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 'Get an UNSIGNED Rialto swap quote for an approved partner,' which clearly specifies the verb, resource, and unique scope. It distinguishes itself from sibling tools like execute_onchain_swap by emphasizing the unsigned nature and self-broadcast requirement.

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 the user must sign and broadcast the transaction themselves, and instructs to call partner_report_fill after broadcasting. This gives clear usage context and a follow-up step, though it doesn't explicitly name alternative tools for non-partner or fully-executed swaps.

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, idempotentHint, and destructiveHint=false. The description adds context about data frequency and market hours (24/7 tokenized stocks vs stock market) and explains that funding_apr_pct is annualized. However, it does not describe return format details or pagination behavior, so it adds some but not rich behavioral context.

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

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

The description is four short sentences, front-loaded with the core purpose, and every sentence adds value: purpose, no-param behavior, with-ticker behavior, and market context. No unnecessary repetition or fluff.

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 read-only tool with 3 optional params and no output schema, the description covers core behavior, parameter effects, and provides market context. It could mention limit behavior or default response shape, but the essential information for invoking the tool is present. Given low complexity, this is fairly complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains ticker semantics (history) and mentions venue pair context, but does not explain the limit parameter at all. It adds partial meaning beyond the schema but leaves gaps, so a 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 hourly funding rates on tokenized-stock perps, names the venues (Arcus + Lighter), and distinguishes behavior based on parameters (latest vs history). This is a specific verb+resource with clear scope, distinguishing it from sibling tools like funding_carry_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?

The description gives clear usage context: without params returns latest values per venue/ticker pair; with ticker returns history. It does not explicitly name alternatives or when-not-to-use, but the parameter-dependent behavior is clearly conveyed. This is clear context without exclusions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds valuable behavioral context: it explains the data sources (Chainlink per-share + pool), the interpretation of high deviation, and that fields are null for markets without a Hood spot. This goes beyond what annotations provide, though it doesn't mention rate limits or pagination.

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 three sentences, each earning its place: the first defines the metric, the second gives interpretive meaning, and the third handles edge cases (null fields). It is front-loaded with the core purpose, contains no fluff, and remains concise despite its informative density.

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 low complexity (one parameter, no output schema), the description covers the essential context: the metric, its interpretation, and null handling. However, it omits any explanation of the parameter's behavior and does not specify the exact return structure beyond 'per ticker'. For a simple read-only query, this is almost complete, but the parameter gap prevents a perfect score.

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 only parameter, min_abs_bps, has no description in the schema (0% coverage) and is not mentioned in the description. While the name is somewhat self-explanatory (minimum absolute basis points), the description does not clarify whether it acts as a filter, a threshold, or something else. With zero schema coverage, the description fails to compensate, leaving the agent to guess at the parameter's role.

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: it reports the deviation in bps between perp mark price and Hood on-chain spot per ticker. It uses specific terminology ('Perp mark price vs Hood on-chain spot') and contextualizes the metric as a basis. However, it lacks an explicit verb like 'list' or 'get', making the action slightly implicit, so it doesn't earn a full 5.

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

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

The description provides interpretive guidance by noting that a large |perp_vs_chainlink_bps| signals a cross-venue opportunity or stale-oracle signal. This implies when the tool could be useful, but it does not explicitly state when to use it over sibling tools like oracle_deviation or hood_basis_snapshot, nor does it mention exclusions. Thus, guidance is present but not fully developed.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about signal components and signal types, but it does not disclose output format, pagination, or other behavioral traits. This is acceptable given annotation coverage, but not rich.

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

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

The description is two sentences, front-loaded with the main purpose, and every word adds value. However, the inline parameter details (signal_type, tickers) could be structured with clearer formatting for faster parsing, but it remains 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?

This is a read-only signal retrieval tool with 4 parameters and no output schema. The description provides a good overview and parameter format hints, but lacks information about output shape, default behavior, or threshold semantics for min_alpha. It is functional but not fully complete.

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

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

Schema description coverage is 0%, so the description carries the burden for parameter understanding. It explains signal_type values and tickers comma-separated format, but omits any explanation of limit or min_alpha, leaving two of four parameters undocumented in both schema and description.

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+resource construction: 'Ticker alpha signals extracted from Reddit', which clearly identifies the tool's purpose. It also distinguishes itself from sibling signal tools by naming the source (Reddit) and specific signal components (novelty, mention velocity, cross-sub spread).

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 use for retrieving Reddit-based alpha signals but provides no explicit guidance on when to use this tool over alternatives like narrative_trade_signals or reddit_market_regime. There is no exclusion or comparison to sibling tools, leaving usage context inferred.

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 idempotentHint=true, so the agent knows this is a safe read operation. The description adds that the output includes confidence and flags to watch, which is useful but does not disclose additional behavioral traits like data freshness or how the regime is computed. No contradiction with 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 sentence that is mostly concise and front-loaded with the core purpose. The parenthetical example list and the addition of 'confidence + flags to watch' make it slightly run-on, but it remains efficient and readable.

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 parameters and no output schema, the description carries the burden of explaining the return value. It mentions regime, confidence, and flags, but 'flags to watch' is vague and undefined. For a simple zero-parameter tool, it is adequate but could provide more detail on the output structure or interpretation.

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

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

There are zero parameters, and the schema is empty with 100% coverage. Baseline for a zero-parameter tool is 4. The description adds no parameter information, but none 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 clearly states the tool provides the current market regime inferred from Reddit chatter, with concrete examples of regime types. It is specific about the resource and output, though it does not explicitly differentiate from sibling tools like reddit_alpha_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?

The description implies the tool is used when you want a synthesized market regime from Reddit sentiment, but it does not explicitly state when to use it over alternatives (e.g., flow_summary or market_events) or mention any exclusions. No alternative tools are referenced.

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 adds behavioral context beyond the sparse annotations (readOnlyHint false, etc.): it notes that wrong keys are rejected, and that the stream is rendered on a live panel. However, it doesn't disclose side effects like whether it persists data or how it handles errors, and since annotations don't indicate safety, the description still carries much of the burden but only partially fills 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?

The description is a single dense paragraph, about 80 words, front-loaded with the main purpose and then key-value enumerations. Every sentence adds useful info: the streaming panel, kind list, agent list, key explanation, call frequency, and message example. It could be more structured but is appropriately 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?

Given the tool has 7 parameters and no output schema, the description provides a good overview but leaves gaps. It explains key, kind, agent, message, and when to call, but does not cover run_id, ticker, payload usage, nor what the response indicates. For a reporting tool with side effects, the description is adequate but not fully complete.

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

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

Schema coverage is 0%, so the description must compensate. It does explain key semantics (OTTO_AGENT_KEY, wrong keys rejected), enumerates kind and agent values, and gives a message format example. But it does not explain run_id, ticker, or payload, which are likely used in certain kinds. Thus it partially compensates for the lack of schema descriptions but not fully.

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: 'Status report from a trading agent' and specifies it should be called at every runbook step. It also lists the distinct kind values, distinguishing it from sibling tools that are all data retrieval or execution tools, making this the unique status-reporting 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?

Explicitly says 'Call at every runbook step', which is clear when-to-use context. It also provides an example message format and notes that messages should be short and human-readable. No explicit alternatives are given, but since this is a reporting tool, the usage context is clear enough and differentiates it from 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 indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds behavioral context by describing what status values are returned (ok|degraded|down) and the specific freshness metrics, giving the agent a clear expectation of the tool's output nature without any 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 two sentences, starts with the core purpose, and packs both the what (metrics) and the when (before trading decisions) without unnecessary filler. Every clause 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 strong annotations and the absence of an output schema, the description provides a solid picture of what the tool returns (freshness, coverage, reference availability, oracle count) and the status scale. This is fully sufficient for an agent to decide when to call and interpret the result.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is no parameter documentation burden. The description adds no parameter specifics because none exist, which is appropriate and earns the baseline for no-parameter tools.

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 reports 'Trust status of the Otto data layer' and enumerates specific data points (per-feed freshness, 24h tick coverage, NASDAQ reference availability, oracle-pause count). This differentiates it from other status-like siblings such as chain_stats or report_agent_status by specifying the exact domain and contents.

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 instruction 'Call before making trading decisions' provides an explicit use case context. However, it does not mention when not to use this tool or contrast with alternative status tools, so it stops short of full exclusions or alternatives 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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context that the tool measures deviation in bps for USDG and other stablecoins, which is valuable beyond the annotations. It does not contradict any annotations and provides the core behavioral context of what is reported.

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, concise sentence that immediately states the key metric. It contains no fluff or redundant information, front-loading the essential purpose. This is an ideal level of brevity for a simple 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 the simple nature (no parameters, read-only, no nested objects, no output schema), the description is nearly complete. It tells the user what is being measured and in what unit. It could mention whether it's a current snapshot or historical, but that is a minor gap not essential for basic understanding.

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 schema provides no details to clarify. The baseline for zero parameters is 4, and the description doesn't need to explain parameters. It does add semantic value by specifying the unit (bps) and the scope (USDG and other stablecoins), which helps interpret any data returned.

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

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

The description precisely defines the tool's purpose: measuring deviation of USDG and other stablecoins from $1 parity in basis points. This is a specific metric with clear scope (stablecoins, depeg risk) that differentiates it from broader market tools. Despite lacking an explicit verb, the noun phrase effectively communicates the data resource.

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: use when you need to assess stablecoin depeg risk or deviation from parity. However, there is no explicit guidance on when not to use it or how it compares to sibling tools like oracle_deviation. The zero-parameter design simplifies choosing it, but exclusions 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?

Annotations already cover readOnly/idempotent/destructive hints. The description adds meaningful behavioral context by explaining that mints/burns indicate tokenized stock supply changes (issuance/redemption). It does not describe pagination or return format but provides useful interpretive guidance beyond 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, front-loaded with the core purpose, and every phrase adds context either about scope or direction semantics. 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?

With 5 parameters and no output schema, the description gives essential context but lacks details on threshold definition, how hours/limit affect results, and return shape. It is adequate for a simple query but would benefit from mentioning what the output contains.

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 0%, so the description must compensate. It hints at 'USD threshold' (min_usd) and direction enum values, but does not explicitly map all parameters. The parameter names (hours, limit, ticker) are self-explanatory, but the description adds only partial semantic value.

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 large on-chain token transfers ('whale flows') and scopes it to 32 stock tokens plus USDG above a USD threshold. It names the resource and verbs ('transfers', 'show') but does not explicitly differentiate from sibling tools like flow_summary.

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 tracking whale flows and notes direction semantics, but it does not provide explicit 'when to use' or alternative tool exclusions. No direct comparison with sibling tools is given, so the context 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.