Otto Data — Robinhood Chain

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

Annotations already indicate readOnly=true and non-destructive. Description adds that results derive from position_closed events and lists output metrics, providing behavioral context 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?

Single block but front-loaded with key metrics and parameter hints. Efficient but could use structured list for readability.

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

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

No output schema, but description lists output fields. Missing explanation for days parameter, otherwise complete for a read-only retrieval tool.

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

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

Schema coverage is 0%, description partially compensates by explaining mode and agent values, but does not clarify the days parameter beyond its 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?

Description clearly states it provides realized trading performance for an agent, listing specific metrics and giving examples for agent and mode. Verb is implied (get/retrieve). Distinguishes from siblings like agent_position_book.

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

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

Implied usage from description but no explicit when-to-use or alternatives. Sibling tools exist but no guidance on choosing agent_performance over others.

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 agent knows it's safe. The description adds transparency by explaining the derivation logic and live price joining, which goes beyond the annotations. 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?

The description is concise and front-loaded with the core purpose. It is dense but not verbose. Minor improvements could be made in structuring the allowed values more clearly, but it remains efficient.

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

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

Given no output schema, the description mentions unrealized P&L in bps and USD and filters by mode and agent, covering the main outputs. It lacks explicit return format details but provides sufficient context for an agent to understand the tool's value.

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%, but the description explains the allowed values for both parameters: agent (gap-trader, narrative-trader) and mode (all, paper, live, onchain). This adds meaning beyond the bare schema, compensating well for the lack of parameter descriptions.

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 it provides a server-side derived open position book for a trading agent, detailing the logic (order_filled minus position_closed) and including unrealized P&L. It distinguishes itself from rebuilding from raw events and mentions specific agents (gap-trader, narrative-trader), differentiating it from sibling tools.

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

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

The description says 'Replaces rebuilding the book from raw agent events,' providing clear guidance on when to use. It also lists mode and agent options. However, it does not explicitly compare to alternative tools or state when not to use, missing a full when-to-use 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 indicate read-only, idempotent, and non-destructive behavior. The description adds context about full historical scope (from genesis) but lacks details on output format, pagination, or other behavioral traits beyond the annotations.

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

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

The description is two sentences and conveys the core purpose without fluff. However, the first sentence is a run-on and could be more structured for clarity.

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

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

With three parameters and no output schema, the description should cover more details like limit behavior, verified_only usage, and return format. The current description only partially addresses tokens_only, leaving 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?

Schema description coverage is 0%. The description explains the tokens_only parameter in Turkish but does not mention the limit or verified_only parameters. This leaves the agent with incomplete understanding of half the parameters.

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

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

The description clearly states that the tool lists contract deployments on Robinhood Chain (Ottoscan) from genesis to present, with a filter for token-only contracts via tokens_only. This is specific and distinguishes it from sibling tools like chain_stats or 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 fetching deployment history but does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance. The sibling tool names are distinct, making the purpose clear by 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 and destructiveHint=false. The description adds that it returns deploy statistics, expanding on the behavioral context 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 a single sentence in Turkish, which is concise but uses a non-English language that may hinder an AI agent. It lacks front-loaded key terms.

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 one optional parameter and no output schema, the description lists some returned metrics but does not specify format or potential filters. The Turkish language reduces completeness for standard agents.

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 coverage and no mention of the 'days' parameter in the description, the agent gets no additional meaning beyond the schema. The default of 30 days is not explained.

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 provides Robinhood Chain deploy statistics including daily deploy/token counts, top deployers, and total contract/verified counts, using Ottoscan analytics. The verb and resource are specific.

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

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

No guidance on when to use this tool versus alternatives like chain_deployments. No exclusion criteria or context hints 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 declare destructiveHint=true, and the description adds critical context: server-enforced limits, automatic event/state updates, and return values (tx_hash, fill details, pnl_bps). 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 detailed yet well-structured, with the core purpose upfront. A bit lengthy but every sentence adds value; could be slightly shorter.

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 9 parameters and no output schema, the description covers return values, side effects, and constraints. Missing parameter explanations for a couple of fields, but overall sufficient for a complex tool.

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

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

Schema description coverage is 0%, but the description explains key parameters (side, qty, usd_amount, slippage_bps, key, agent). Missing details for 'reason' and 'run_id', but overall adds significant meaning beyond 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 executes a real on-chain swap, specifying the router, wallet, and two sides (buy/sell) with detailed outcomes. It distinguishes from sibling tools by focusing on swap execution, with automatic state updates.

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 executing swaps and lists constraints (guardrails, caps), but does not explicitly state when to avoid using it or suggest alternatives. Context is clear but lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint true, destructiveHint false, and idempotentHint true, so the agent knows it is a safe read operation. The description adds the specific data elements returned, but does not disclose additional behavioral traits like data freshness, pagination, or authentication requirements.

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

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

The description is a single sentence that efficiently conveys the core functionality. However, the use of Turkish may reduce readability for English-centric agents, and the lack of structure (e.g., bullet points) slightly detracts from clarity.

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

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

Given the simple tool with one parameter, the description is incomplete. It does not explain how 'ticker' is determined (no parameter), what time range 'hours' covers, or whether the data is historical or real-time. Annotations partially compensate for safety, but the overall context is weak.

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

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

The single parameter 'hours' has no description in the schema (0% coverage), and the description does not mention it at all. The agent has no information about the parameter's purpose, format, or effect, which is critical for correct invocation.

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 provides a whale flow summary by ticker, specifying included metrics (transfer count, volume, mint/burn, largest transfer). However, it does not explicitly distinguish from sibling tools like 'token_flows', and the Turkish language may reduce clarity for some agents.

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 usage guidance is provided. The description does not mention when to use this tool, when not to use it, or how it compares to alternatives such as 'token_flows' or 'hood_gaps_summary'. This lack of context can lead to incorrect tool 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 and idempotentHint=true, so the description's mention of 'deterministic' and 'NOT orders' adds minimal value. No additional behavioral traits are disclosed beyond what annotations provide.

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

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

The description is concise and front-loaded with the main purpose. It packs necessary details without excessive verbiage, though it could be slightly streamlined.

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 only one parameter and no output schema, the description thoroughly explains all output fields (funding rate, APR, gap, label, risk flags) and the label logic. It is complete for the tool's complexity.

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 0% schema description coverage, but the description explains its purpose: 'filters on |perp_vs_chainlink_bps|.' This adds essential meaning not present in 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 computes deterministic funding-carry candidates using perp funding and perp-vs-spot basis. It specifies per-ticker outputs: funding rate, annualized APR, gap in bps, and label. This distinguishes it from sibling tools like gap_trade_signals and perp_funding.

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 explains the filtering parameter min_abs_bps and explicitly states 'Signals are NOT orders,' which guides appropriate use. However, it does not explicitly compare with other tools or state when not to use this tool.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds valuable transparency: deterministic nature, signal suppression during regular session, and risk flags (oracle_paused, stale, low_liquidity, earnings_within_48h). This goes 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 concise (three sentences), front-loaded with purpose, and structured logically: function, outputs, usage notes. 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?

The description covers tool purpose, output fields, and timing constraints well, but lacks parameter explanation and does not fully describe return format (e.g., structure of statistics). For a tool with no output schema, more detail on return values would improve 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?

Schema description coverage is 0%, so the description must explain parameters. It does not mention 'days' or 'min_abs_bps' at all, leaving the agent to guess their meaning and effect on output.

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 provides deterministic signals for the gap-trader strategy, listing specific output fields (overnight gap, signal type, statistics, hit rate, risk flags). It distinguishes this tool from order placement, 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 explicit usage guidance: signals are not orders, and the most informative window is pre-open 09:15-09:29 ET with suppression during market open. It does not explicitly mention alternatives or when not to use, but the context 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 readOnly and idempotent hints. The description adds that it combines two signals and deduplicates fan-out, but does not disclose data freshness, rate limits, or other behavioral traits. Adequate given annotation coverage.

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

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

Two sentences in Turkish, concise and to the point. No unnecessary information. Could be slightly more structured with explicit parameter details.

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

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

Given the complexity of combining two signals and no output schema, the description explains the purpose but does not describe output format or how scores are computed. It is somewhat complete but leaves gaps for an agent unfamiliar with the domain.

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?

One parameter (min_alpha) is explained only by its title 'Min Alpha' and the description mentioning 'alpha skoru'. With 0% schema description coverage, the description should provide more detail on what the value means or constraints. It is minimally sufficient.

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

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

Description clearly states the tool combines Reddit attention/alpha scores with live basis for Hood tokenized shares to identify tokens with both social interest and on-chain premium/discount. It also mentions deduplication of fan-out. This distinguishes it from siblings like reddit_alpha_signals and 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?

Implied usage is clear: the tool is for finding tokens with simultaneous social interest and on-chain basis signals. It does not explicitly state when to avoid or mention alternatives, but the combination is well-defined.

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. The description adds meaningful behavioral context: returns historical minute data, newest first, with a max limit of 5000. 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?

The description is concise, with two sentences that front-load the core function. However, it is in Turkish, which may reduce clarity for non-Turkish agents.

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 two-parameter tool, no output schema, and annotations, the description covers the key points: history type, granularity, ordering, examples, and limit constraint. Lacks explanation of 'basis' but is otherwise 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 has 0% description coverage, so description must compensate. It explains limit maximum (5000) and gives example tickers. However, it does not explain the 'basis' concept, the default limit (200), or the ticker format. Partial but helpful.

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

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

The description clearly states the tool retrieves minute-by-minute basis history for a ticker, mentions example tickers, and specifies ordering (newest first) and limit constraint. This distinguishes it from siblings like '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?

No explicit guidance on when to use this tool vs alternatives. The ordering and limit hints are present but no contrast with similar tools like 'hood_basis_snapshot'.

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. The description adds value by detailing the output fields (chainlink_px, ref_last, basis_bps, etc.) and their meanings, which is helpful 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 a single sentence with a clear list of fields. It is front-loaded with the purpose and efficiently structured, though the use of Turkish may reduce clarity for non-Turkish readers.

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

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

Given no output schema and zero parameters, the description fully explains the tool's purpose and all return fields with their meanings. No gaps remain for an agent to understand invocation or results.

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

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

There are no parameters, and the schema coverage is 100% (empty object). Per guidelines, a baseline of 4 applies since the description does not need to add parameter information.

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 current basis (premium/discount) snapshot for Robinhood Chain tokenized shares, and lists the specific fields returned. This distinguishes it from siblings like hood_basis_history which focuses on historical data.

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

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

The description implies it is used to get current basis data, but does not explicitly state when to use it versus alternatives (e.g., hood_basis_history for historical). No exclusions or prerequisites mentioned.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe read operation. The description adds that the tool returns a registry of feeds with addresses, providing useful behavioral context beyond annotations. 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?

Single sentence that is concise and front-loaded, covering the essential purpose without extraneous 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 registry with no parameters and annotations covering safety, the description is reasonably complete. It lacks description of return format, but given no output schema, it provides enough context for an agent to infer the tool's function.

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

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

No parameters exist, so baseline is 4. The description adds no parameter information but is not 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 it is a registry of tokenized stock and crypto feeds with addresses, using a specific verb ('registry') and resource ('feeds'). It distinguishes itself from sibling tools like hood_pools and hood_gaps_live by focusing on feed addresses.

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 does not provide any guidance on when to use this tool versus alternatives. It only describes what the tool contains, not context or 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 as false, which covers the safety profile. The description adds that data is session-based and historical, but does not detail any additional behavioral traits such as pagination, response format, or data source. With annotations present, a score of 3 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 short sentence in Turkish, efficient and without waste. However, it is not structured (e.g., bullet points) and may be less accessible due to language. It earns its place but could be slightly more formalized.

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

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

There is no output schema, so the description should explain what data is returned. It only mentions 'each night/weekend separate line' but does not describe columns or data types. For a tool with two parameters and no output schema, this is insufficient.

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. However, it does not explain the 'days' parameter (default 14) or elaborate on 'ticker' beyond the property name. The agent gains no additional semantic understanding from the 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 clearly states it provides session-based gap history for a ticker, with separate lines for each night/weekend. The name and description together specify the resource and action, distinguishing it from siblings like hood_gaps_live (live) and hood_gaps_summary (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 historical session-level gap analysis, but does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria. The agent must infer context from the name and 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, idempotentHint, and destructiveHint. The description adds a key behavioral detail: if market is open, it returns 'regular'. This provides context beyond annotations, though the exact output format remains unspecified.

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, no wasted words. The description is front-loaded with the main purpose and includes an important behavioral note. Highly efficient.

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

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

Given zero parameters, no output schema, and annotations covering safety, the description provides the core behavioral detail (market-open behavior). However, it does not describe the output structure or provide examples, which would be beneficial for 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 tool has zero parameters, so schema coverage is complete. The description does not need to add parameter semantics. According to guidelines, baseline for 0 params is 4.

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

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

The description clearly states the tool shows live off-hours gaps, specifying what it displays (tickers most premium/discounted relative to last close). It also notes behavior when market is open, distinguishing it from siblings like hood_gaps_summary 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 use for live off-hours gap data, but does not explicitly mention when not to use or provide alternatives. Sibling tool names (e.g., hood_gaps_summary, hood_gap_sessions) offer implicit differentiation, but explicit guidance is 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?

Description adds useful context beyond annotations: computes gap statistics from historical data, measures deviation when NASDAQ is closed. Annotations already declare readOnlyHint=true and idempotentHint=true, and description reinforces this without 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?

Description is concise (two sentences), front-loaded with key information. Could be slightly more structured, but no extraneous content.

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

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

Adequately explains purpose and behavior given the tool's simplicity and annotation support. However, lacks parameter documentation and output format description, leaving some gaps for an agent.

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

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

The only parameter 'days' has a default of 14 but is not mentioned in the description. With 0% schema description coverage, the description should explain this parameter. It does not, leaving its purpose unclear.

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

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

Description clearly states it provides overnight/weekend gap statistics with specific metrics (mean, min/max, last) and unit (bps). It explains the rationale (24/5 trading, NASDAQ closure). However, it doesn't explicitly differentiate from sibling tools like hood_gap_sessions or hood_gaps_live.

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

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

No explicit guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, use cases, or when not 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, destructiveHint=false, and idempotentHint=true, indicating a safe read operation. The description adds that the output is flattened from all research cards and sorted by date, providing some behavioral context beyond annotations. 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 extremely concise, consisting of two short sentences. It front-loads the key purpose (off-hours catalysts) and audience, 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?

With no output schema, the description explains what the tool returns (dated catalysts, flattened, sorted) and its purpose. However, it does not describe the fields in each catalyst entry, which would help an agent understand the returned structure. For a tool with no parameters, this is a minor 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?

There are no parameters, so the schema coverage is effectively 100%. The description does not need to explain parameters. For zero-parameter tools, the baseline is 4.

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

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

The description clearly states the tool retrieves dated catalysts that can move token prices when NASDAQ is closed, aggregated from research cards. It specifies the off-hours context, distinguishing it from similar tools that may operate during market hours. However, it doesn't explicitly differentiate from siblings that might also return research-based data.

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

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

The description says it is 'for agents tracking overnight gap and weekend risk,' which suggests when to use it. However, it does not provide explicit exclusions or alternatives, leaving some ambiguity about when not to use this tool versus siblings like hood_gap_sessions or hood_attention.

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 and idempotentHint, so the description's contribution is the update frequency (every 5 minutes) and the data sources (Uniswap and Chainlink). This adds value beyond annotations, though it does not detail what specific tokens are monitored.

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 in one short paragraph, front-loading key information (what data is returned) and ending with update frequency. 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 zero-parameter, read-only tool with no output schema, the description provides essential information: returned fields and update cadence. However, it could be more complete by naming the specific tokens or pools monitored, or stating that it returns data for all monitored pools. Still adequate for typical use.

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

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

There are no parameters; the input schema is empty with 100% coverage. The description correctly omits parameter details, and no additional meaning 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?

Description clearly states the tool returns monitored Uniswap pool data: token price, liquidity (USD), and deviation from Chainlink oracle price. It also specifies update frequency (every 5 minutes). This distinguishes it from sibling tools like hood_basis_snapshot or hood_gaps_live.

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 suggests usage when pool price, liquidity, or oracle deviation data is needed, but it does not explicitly state when to use or not use this tool, nor does it reference alternatives among the sibling tools. Usage context is implied but not direct.

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 indicate read-only, idempotent, non-destructive. The description adds context of being 'minimal fast' and lists specific output fields, which is helpful 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 sentences: first states purpose and output, second provides usage guidance. No fluff, well-front-loaded.

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

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

For a simple one-parameter tool with annotations, the description fully covers what it does, what it returns, and when to use 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?

Only one parameter 'ticker' with 0% schema description coverage. The description clearly implies it's a stock ticker symbol for a single Hood asset, compensating for the missing schema 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 states it provides a 'minimal fast quote for one Hood ticker' with specific data fields, distinguishing it from 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?

Explicitly says 'Use for sizing and fill pricing instead of pulling the full 32-ticker snapshot', providing clear when-to-use guidance and an alternative.

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 indicate readOnly, idempotent, non-destructive. Description adds context: mentions static research report, highlights api_data for precise numbers, 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?

Dense but efficient paragraph front-loads purpose and key details. No wasted words, though could be slightly more structured with bullet points for readability.

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

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

Given no output schema, description adequately covers fields, modes, and nuance about api_data. Lacks explicit output format, but sufficient for an agent to understand what the tool returns.

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 coverage, description fully explains the single parameter: ticker default empty, and what happens in each case (single card vs full report). Adds meaning beyond 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?

Description clearly states it provides a deep research report for Hood tokenized stocks with scores, ratings, and four analysis columns. Distinguishes between providing a ticker or not, which sets it apart from sibling tools.

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

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

Explicitly says if ticker provided, get a single card with live basis join; if empty, get full report. Provides clear context on when to use each mode, but lacks explicit comparison to alternatives.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context beyond annotations, notably that missing upstream sources fail-soft (field is null), which is a graceful degradation trait not captured in 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 primary purpose and followed by details and fail-soft behavior. Every sentence adds value with no 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 description lists all major data categories included in the brief, addresses fail-soft behavior, and implies it aggregates from multiple sources. Without an output schema, this provides sufficient context for an agent to understand the tool's capabilities.

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 required parameter (ticker) with 0% description coverage. The description only implies 'ticker' is a stock symbol, adding minimal semantic value. Since the parameter is common and self-explanatory, a score of 3 is appropriate given no explicit parameter documentation.

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 provides a 'one-call brief' for a single Hood ticker, listing specific data points (live quote, research card, earnings risk, etc.). It explicitly mentions it replaces 6-7 separate tool calls, distinguishing it from sibling tools that likely provide individual data (e.g., hood_quote, hood_stock_research).

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 indicates this tool is for when an agent researches one ticker and needs a comprehensive brief, replacing multiple calls. It implicitly suggests using individual sibling tools for specific data needs, but does not explicitly state exclusions or alternatives.

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. The description adds no behavioral context beyond listing parameters.

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

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

Single sentence with mixed language, but packs essential parameter info. Could be more structured but is reasonably 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?

No output schema. Missing details on return format and pagination. With 4 parameters and no param descriptions in schema, the description is only partially 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?

Despite 0% schema description coverage, the description explains symbols and event_type formats with examples and importance range. However, limit and min_importance are not described.

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

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

The description clearly states the tool retrieves machine-readable news events for crypto and stocks. It distinguishes from siblings which are mostly blockchain-specific tools.

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

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

No guidance on when to use this tool vs alternatives like hood_attention or reddit_alpha_signals. The agent must infer usage from 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, idempotentHint, and destructiveHint. The description adds value by explaining the bias field, live Chainlink price, basis, risk flags, and importantly clarifies that signals are not orders. 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?

Three sentences, front-loaded with core purpose. Every sentence adds distinct value: output composition, bias explanation, and non-order clarification. 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?

Covers output fields, bias logic, and non-order nature adequately for a read-only tool with annotations. However, lacks explicit parameter documentation and does not specify return format (list vs single object). Slightly incomplete given no output schema.

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

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

The schema has two parameters (hours, min_alpha) with defaults but zero description coverage. The description mentions 'highest-alpha' and 'alpha_score', implying min_alpha filters, but does not explain 'hours' nor give explicit parameter semantics. With 0% coverage, the description fails to compensate sufficiently.

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 produces 'deterministic candidates for the narrative-trader strategy' using the highest-alpha Reddit signal per ticker, distinguishing it from sibling tools like gap_trade_signals or funding_carry_signals. It also explicitly says 'Signals are NOT orders', avoiding confusion with order placement tools.

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

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

The description gives context that this tool is for the narrative-trader strategy and advises using the 'reason' field in reports and charts. However, it does not explicitly state when not to use it or mention alternative tools for different strategies.

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 readOnly and idempotent hints. The description adds valuable context about the return format (deviation sorted by absolute value), status categories (ok, warning, alert), and a caveat about low liquidity pools. This goes beyond the annotations.

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

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

The description is extremely concise, using a few sentences and bullet-like format for status ranges. It front-loads the main purpose and provides all essential information without any 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 list tool with one parameter, the description is fairly complete: it explains the output (deviation in bps, status categories), ordering (by absolute value), and a caution about low liquidity. Minor gaps include not explicitly stating that it returns multiple rows.

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 explain the only parameter 'min_abs_bps'. While the parameter name suggests it is a filter for minimum absolute deviation in basis points, the description should explicitly state this to aid the agent.

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 shows Chainlink vs Uniswap pool price deviation in basis points, ordered by absolute value, and defines status thresholds. It distinguishes this tool as a specific metric, though it could be more explicit about returning a list of pools.

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

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

There is no explicit guidance on when to use this tool versus alternatives. The description implies checking deviation for pool price health, but it does not mention when not to use it or how it compares to siblings like hood_pools or market_events.

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?

Description adds substantial behavioral context beyond annotations: hourly granularity, latest vs history modes, meaning of funding_apr_pct as annualized %, and rationale for weekend/overnight rates. No contradiction with annotations (readOnly, idempotent).

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

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

Two sentences, front-loaded with main purpose, no redundant words. Every sentence adds essential 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?

Description explains the core functionality and domain context well. However, it does not describe the limit parameter or output format in detail (though funding_apr_pct is mentioned). For a read-only tool with no output schema, this 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 has 3 parameters with 0% description coverage. Description implies ticker triggers history and mentions 'venue+ticker pair', partially covering venue and ticker. However, limit and exact parameter behavior are not explicitly described. Description adds value but does not fully compensate for lack of schema descriptions.

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

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

Description clearly states it provides hourly funding rates on tokenized-stock perps, specifies venues (Arcus, Lighter), and distinguishes behavior with and without parameters: latest per venue+ticker pair vs history with ticker. This differentiates it from siblings like perp_spot_basis.

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?

Description explains that without parameters it gives latest values, with ticker it gives history. Provides context about 24/7 trading vs stock market hours. Does not explicitly name alternative tools, but the sibling list makes differentiation 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 indicate readOnly=true, idempotent=true, destructive=false. The description adds that fields are null for markets without a Hood spot and that large absolute bps indicates opportunity or stale oracle, providing context beyond annotations. 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?

The description is concise with two sentences, no fluff, and front-loaded with the main idea. However, it could be improved by integrating the parameter explanation succinctly.

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

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

Given no output schema, the description explains output meaning (deviation in bps, null fields) and data sources. It fairly covers interpretation, but could mention output format or potential aggregation across tickers.

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 does not mention the sole parameter 'min_abs_bps' (default 0). Schema coverage is 0%, so the description should compensate but fails to explain that this parameter filters results by minimum absolute basis points.

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 computes the basis between perpetual mark price and Hood on-chain spot price (Chainlink per-share + pool) in bps per ticker. It distinguishes itself from siblings like 'hood_basis_snapshot' by specifying the exact comparison and purpose.

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 detecting cross-venue opportunities or stale-oracle signals, but lacks explicit guidance on when to use this tool versus alternatives like 'hood_basis_snapshot'. No when-not-to-use or prerequisite conditions 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 (readOnlyHint, idempotentHint, destructiveHint false) are consistent. Description adds signal components but no additional behavioral details (e.g., rate limits, data freshness). 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?

Extremely concise: two sentences front-load the core purpose and key parameter details. 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?

No output schema, so description should hint at return format. It mentions components but not structure or pagination. Annotations provide safety hints. Adequate but could detail what 'alpha signals' look like as output.

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%. Description adds meaning for signal_type (enumerates possible values) and tickers (comma-separated). However, limit and min_alpha are only described by schema defaults; no additional semantics beyond that.

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 extracts Reddit ticker alpha signals, lists components (novelty, mention velocity, cross-sub spread) and signal types (ticker_alpha, crowded_trade, etc.). It distinguishes from siblings by specifying Reddit-based signals.

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

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

No explicit guidance on when to use this tool versus alternatives like reddit_market_regime. The description implies usage for Reddit-derived alpha signals but lacks when-not or alternative 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 indicate read-only, non-destructive behavior. The description adds context about the source (Reddit chat) and outputs (regime, confidence, flags), which is valuable beyond the annotations. 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?

A single, well-structured sentence with no extraneous content. It front-loads the action and provides examples efficiently.

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 zero parameters and no output schema, the description adequately explains the tool's purpose and outputs. It could mention update frequency or limitations, but is largely 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?

No parameters are defined, and schema coverage is 100%. The description adds value by explaining the output nature, so baseline 4 is appropriate.

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

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

The description clearly states the tool extracts the current market regime from Reddit chat, provides example outputs (mag7_only_rally, risk_on_call_chase), and mentions confidence and flags. It distinguishes itself from siblings like reddit_alpha_signals by focusing on regime extraction.

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 obtaining Reddit sentiment-based market regime, but does not explicitly state when to use this tool versus alternatives like reddit_alpha_signals. No exclusions or comparisons 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?

The description adds behavioral context beyond annotations by mentioning the live panel rendering and key rejection for wrong keys. However, it does not clarify the full behavioral impact (e.g., if it mutates state or logs data), and annotations only provide basic hints. The description adds some value but not comprehensive transparency.

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 and well-structured: it starts with the purpose, then lists possible values, key requirements, and usage tips. Every sentence adds value, but it could be slightly more compact.

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

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

Given the tool's complexity (7 parameters, no output schema, no param descriptions), the description covers the core purpose, required parameters, and usage patterns. It lacks details on optional parameters and return values, but overall it is fairly complete for an agent to understand how to use the tool.

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

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

With 0% schema description coverage, the description compensates by explaining required parameters (key, kind, message) and giving examples for kind and agent. However, optional parameters (run_id, ticker, payload) are not explained, leaving gaps. The description adds significant value for some parameters but not all.

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 is for reporting status from a trading agent, with a specific resource (the live panel on ottodata.app/agents). It distinguishes from sibling tools like agent_performance and agent_position_book by describing its streaming status update purpose.

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 usage guidance: 'Call at every runbook step' and advises to keep messages short and human-readable. It also notes that wrong keys are rejected. However, it does not explicitly state when not to use this tool versus alternatives.

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, destructiveHint, and idempotentHint. The description adds no behavioral context beyond stating the metric, such as whether it returns a time series, latest snapshot, or historical data.

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. However, it is written in Turkish while the tool name is English, which may reduce clarity for non-Turkish agents.

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

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

Given no parameters and no output schema, the description is too brief. It lacks details on data format, frequency, supported stablecoins, or how to interpret the returned value.

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

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

The input schema has zero parameters, so no parameter information is needed. The description does not need to add meaning beyond what the schema provides.

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

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

The description clearly states that the tool measures deviation from $1 parity for USDG and other stablecoins, specified in basis points (bps). It identifies the metric and asset class, but lacks a verb like 'retrieve' or 'get' to indicate it returns data.

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

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

No guidance on when to use this tool versus alternatives like oracle_deviation or hood_basis_snapshot. The description does not mention prerequisites, context, or 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 readOnly, idempotent, non-destructive. The description adds context about direction meaning (mint/burn = issuance/redemption) but does not disclose other behavioral traits like rate limits or pagination. 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 short but mixes Turkish and English awkwardly. It front-loads the core purpose but the sentence about mint/burn is somewhat redundant. Could be more structured and clear.

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

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

With 5 parameters, no output schema, and 0% schema coverage, the description lacks details on return format, data structure, or usage patterns. It provides only minimal context, leaving significant gaps for agent invocation.

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

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

Schema coverage is 0%, so description must compensate. It only explains the 'direction' parameter (mint|burn|transfer) and hints at min_usd via 'USD threshold', but leaves hours, limit, ticker, and min_usd undefined. Incomplete semantic 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 indicates the tool retrieves large on-chain token transfers (whale flows) for 32 stock tokens and USDG, with direction options mint|burn|transfer. However, it does not differentiate from sibling tools like flow_summary, leaving some ambiguity.

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

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

No explicit guidance on when to use this tool versus alternatives. The description provides context (e.g., large transfers, direction types) but no conditions, prerequisites, or comparisons to siblings.

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