PredMCP

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

Annotations only indicate it's not read-only. The description adds key behavioral details: requires email, returns key+config, free tier (100 calls/day, one key per IP). This exceeds 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?

Two sentences with no wasted words. First sentence gives action and precondition, second adds constraints. Front-loaded and efficient.

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

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

Given the simple one-parameter tool with no output schema, the description adequately covers input, output (key and MCP config), and usage limits. It could mention error cases, but is largely 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 100% with a clear description for 'email'. The overall description reinforces the requirement and adds context about its use (identification, recovery).

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 'Generate a free PredMCP API key', clearly indicating the verb (generate) and resource (API key). It distinguishes this write tool from the many read-only 'get_*' siblings.

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

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

The description implies when to use: to obtain an API key for using PredMCP. It doesn't explicitly state when not to use or provide alternatives, but the context of sibling tools makes it clear this is the only creation 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 readOnlyHint=true and openWorldHint=true, so the description adds value by specifying the data source (free Yahoo Finance), the set of indicators, and the inclusion of 1d change. 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?

Two sentences, front-loaded with the key indicators, concise and efficient. No superfluous text.

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 sufficient for a parameterless tool with no output schema. It lists the exact indicators and source. Minor omission: does not mention output format or error handling, but given simplicity and annotations, it is largely 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?

No input parameters exist, so schema coverage is 100% trivially. Per guidelines, 0 parameters yields a baseline of 4. The description does not need to add parameter meaning.

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

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

The description clearly specifies the tool returns macro indicators (DXY, US10Y yield, S&P 500, gold, VIX) from free Yahoo Finance with raw values and 1d change. This distinguishes it from siblings like get_macro_context, which likely provides different or more detailed macro data.

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

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

The description implies usage for obtaining basic macro data, and mentions a 'Pro' version with additional indicators. However, it does not explicitly state when to use this tool versus alternatives like get_macro_context or get_macro_liquidity, nor does it provide 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 indicate read-only and open-world. The description adds valuable behavioral context: the computation formula (annualized funding minus costs), and that each candidate costs an orderbook call (from parameter description). 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?

Two concise sentences. The first explains the tool's computation, the second contrasts with a sibling. No wasted words; every sentence is informative.

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

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

Despite no output schema, the description sufficiently describes the computed outputs: net carry, break-even holding period, stability score. Given the tool's complexity, this is complete and informative.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds minimal extra value for parameters beyond restating the cost implication, which is already in the schema for top_n.

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

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

The description clearly states what the tool computes: net funding carry after costs, including break-even holding period and stability score. It also explicitly distinguishes from sibling tool 'get_top_funding_rates' by noting that shows gross carry, making the purpose very 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?

The description provides clear guidance on when to use this tool (for net carry) and contrasts with the gross alternative. While it doesn't exhaustively list all alternatives, it gives a direct comparison and implies the 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=true and openWorldHint=true. The description adds value by specifying the exact exchanges, the scope (hot wallets only), and the data source limitation ('Etherscan free tier'). It also explains the bullish/bearish interpretation of outflow vs inflow, which is useful behavioral context beyond what annotations provide. 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 consists of only two sentences: the first clearly states the tool's function, and the second adds interpretation and data source context. Every sentence is meaningful and there is no wasted text. It is front-loaded with the core purpose.

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 only 2 parameters with full schema coverage, good annotations (readOnlyHint, openWorldHint), and no output schema, the description covers the key aspects: what data is returned, from which exchanges, and how to interpret it. It could mention the output format or any rate limits, but overall it is sufficiently complete for a simple data query tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not provide additional details about the parameters beyond what the schema already includes (exchange filter and window_hours). It mentions 'over a window' in general but adds no new semantics for either parameter.

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

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

The description clearly states the tool returns 'Net ETH outflows across known CEX hot wallets' over a specified window. It names the specific exchanges (Binance, Coinbase, OKX, Kraken, Bitfinex) and the direction interpretation (outflow = bullish, inflow = bearish), distinguishing it from sibling tools that focus on other metrics like funding rates or order books.

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 context ('Outflow = bullish... Inflow = distribution pressure') but does not explicitly state when to use this tool versus alternatives. It mentions 'Etherscan free tier' hinting at data source limitations but lacks clear when-to-use or when-not-to-use guidance compared to the many 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 and openWorldHint=true. The description adds value by disclosing the specific signals aggregated (funding outlier, whale imbalance, OI/volume ratio, momentum), which goes beyond what annotations provide. No contradictions.

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

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

Two sentences with no waste. First sentence explains what it does, second sentence highlights the value proposition. Front-loaded with purpose and output format.

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

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

Despite no output schema, the description clearly defines the output format (directional score -100 to +100, strength score 0-100). The tool is a composite, and the description covers inputs, outputs, and rationale. Highly complete for decision-making.

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?

Input schema has 100% description coverage with parameter descriptions for asset, whale_window_minutes, and min_whale_notional_usdc. The tool description reinforces the aggregation concept but adds minimal detail beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool aggregates multiple signals (funding outlier, whale imbalance, OI/volume ratio, momentum) into a single directional score (-100 to +100) and strength score (0-100). The verb 'aggregates' and resource 'conviction score' are specific, distinguishing it from sibling tools that provide individual components.

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 'One call replaces 6+ lookups, returns a clean number for LLM decisions,' implying it should be used when a consolidated score is needed instead of individual signals. It does not explicitly state when not to use it, but context from sibling tools (e.g., get_funding_outliers, get_whale_convergence) provides 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 and openWorldHint. Description adds context: data source (predictedFundings feed), sorting by annualized spread, and the delta-neutral carry strategy. No destructive behavior implied. Provides value beyond annotations by explaining the nature of the 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?

Three sentences, no redundancy. Key information front-loaded: purpose, data source, use case. Every sentence adds value. Ideal length for quick comprehension.

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 two optional parameters and no output schema, the description covers the essential: data source, sorting, strategy. Does not specify output format but is sufficient for an agent to use the tool. Sibling tools are distinct, so context 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 100%, so baseline is 3. Description does not add new parameter semantics beyond what schema provides (limit and min_spread_annual_pct). However, it mentions 'annualized spread' which clarifies the meaning of min_spread_annual_pct. No significant enhancement.

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?

Clearly states it predicts funding spreads between Hyperliquid, Binance, and Bybit per asset, using HL's predictedFundings feed. The verb 'get' combined with 'cross-venue funding' precisely identifies the resource. Differentiates from sibling tools like get_funding_rates by focusing on spreads between venues.

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 describes the use case: 'delta-neutral carry' and strategy of longing lowest funding and shorting highest. Implicitly advises when to use but lacks explicit when-not or alternative tool references. Still clear enough for an agent to infer appropriate 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 provide readOnlyHint=true and openWorldHint=true, covering safety. The description adds value by detailing the analytical approach (multiple averages, anomaly flags) beyond the annotations, but does not disclose additional behavioral traits like rate limits or side effects.

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 (two sentences) and front-loaded with the core functionality. It could be slightly improved by integrating a usage hint, but overall efficient.

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

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

Given the complexity of term-structure analysis, the description covers the key components (current vs averages, flags for anomalies). However, without an output schema, more detail on the output format (e.g., single score vs. list) would enhance 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 coverage is 100%, with a clear description for 'asset'. The description does not add any extra meaning or context for the parameter, so it meets the baseline of 3.

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

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

Description clearly states it performs term-structure analysis of Hyperliquid funding, comparing current, 8h avg, 24h avg, and 7d baseline, and flags anomalies. It distinguishes from siblings like get_funding_rates by noting it is 'more nuanced than raw funding rate'.

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 for deeper analysis than raw funding rates, but does not explicitly state when to use it versus alternatives (e.g., get_funding_momentum). No exclusions or when-not-to-use guidance 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 readOnlyHint=true and openWorldHint=true, so the tool is safe and open-ended. The description adds the insight that spike vs baseline is a stronger signal, which is valuable 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-load the purpose and key insight without any wasted words. Every sentence adds value.

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

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

No output schema exists, but the tool's purpose is simple and the description covers inputs and logic. Output format is implied (list of perps), and the description is sufficient given the context.

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

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

Schema coverage is 100%, and the description adds interpretive context (spike vs baseline stronger) that goes beyond the schema's parameter descriptions, which already define days and min_deviation_factor.

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 finds Hyperliquid perps with current funding rate deviating significantly from their 7-day average, which distinguishes it from siblings like get_funding_rates and get_top_funding_rates.

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 outlier detection based on deviation, but does not explicitly state when to avoid or mention alternatives. However, context signals and sibling names provide implicit 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 and openWorldHint=true. The description adds interpretation (positive/negative rates), but does not disclose data freshness or rate limits. Still, it provides useful 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 two sentences with no unnecessary words. The first sentence states the purpose, the second adds interpretative context. Each sentence earns its place.

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

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

Given no output schema, the description could mention the output format, but for a simple list of funding rates the semantic interpretation provided is sufficient. The tool is low-complexity with 1 parameter.

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

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

Schema coverage is 100% and the description reinforces the optional 'coins' parameter with an example (e.g., ['BTC', 'ETH']), adding value beyond the schema's 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 'current funding rates for Hyperliquid perpetuals' and explains the meaning of positive/negative rates. This distinguishes it from sibling tools like get_funding_outliers and get_top_funding_rates.

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 by showing how to omit coins for all assets, but does not explicitly state when to use this tool versus alternatives like get_funding_outliers or get_top_funding_rates.

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: true, openWorldHint: true) indicate a safe read operation and non-exhaustive results. The description adds that the tool flags spreads above a threshold, which is consistent. However, it does not disclose output format, pagination, or how the spread is computed beyond 'mispriced relative.' Adds value beyond annotations but could be more explicit.

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 first sentence states the core action and second explains the concept. Front-loaded and efficient.

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

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

The tool is simple (1 optional parameter, read-only) and the description covers the key idea. However, without an output schema, mentioning the return structure (e.g., list of markets with spread percentages) would improve completeness. Otherwise adequate.

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

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

Schema coverage is 100% and the single parameter min_spread_pct is well-described with default, min, max, and meaning. The tool description reinforces its role as a threshold. No additional semantics needed; baseline 3 with coverage, and description adds context, justifying a 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 identifies the tool's purpose: finding the same underlying market on HIP-4 and Polymarket and flagging spreads above a threshold. It uses specific verb 'Finds' and specifies the resources (HIP-4, Polymarket), distinguishing it from sibling tools like get_pm_hl_divergences which compare Polymarket and Hyperliquid funding rates.

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 mispricing but does not explicitly state when to use this tool versus siblings like get_pm_hl_divergences or get_funding_outliers. No guidance on when not to use or how to interpret threshold. Provides clear context but lacks 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 provide readOnlyHint and openWorldHint. The description adds meaningful context about targeting near-certain resolution for late-game positioning, which goes beyond the annotations. However, it does not disclose rate limits or data freshness, which would be ideal.

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 action and purpose, with no extraneous words. Every sentence adds value.

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

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

Despite good annotations and parameter coverage, the description lacks any information about the output format. With no output schema, the agent is left uncertain about what the tool returns, which is a notable gap 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?

Schema coverage is 100% with descriptions for both parameters. The description does not add new meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states it retrieves sports prediction markets on Polymarket that are closing soon with a high-certainty outcome. This distinguishes it from siblings like get_markets_near_resolution or get_odds, as it specifically targets late-game sports markets with near-certain outcomes.

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 late-game positioning but does not explicitly compare with alternative tools like get_markets_near_resolution or get_signals. No when-to-use or when-not-to-use guidance is provided, leaving the agent to infer context.

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

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

Annotations indicate readOnlyHint and openWorldHint. The description adds context about the estimation method and interpretation of results (stronger support/resistance with higher liquidity), which goes beyond annotations without contradicting them.

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 deliver all critical information efficiently. The first sentence states purpose and computation, the second adds context. 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 one-param tool with no output schema, the description provides sufficient context about what the output represents and its interpretation. However, it lacks explicit mention of output format or structure.

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

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

Schema coverage is 100% with a single parameter 'coin' described as an asset ticker. The description adds minimal extra meaning beyond the schema, maintaining the baseline score.

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 'estimated price levels where mass liquidations concentrate' for a Hyperliquid perp, specifying the computation method. It distinguishes itself from siblings as the only tool focused on liquidation clusters.

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 when needing liquidation concentration levels for a perp, but does not explicitly state when to use or not use it, nor mention alternative tools for similar data.

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 the description adds that it provides a 'snapshot' from free sources. While this is consistent, no additional behavioral traits beyond annotations are disclosed (e.g., data freshness, error conditions).

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 tool's output, front-loading the key information without 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?

Given zero parameters, no output schema, and annotations covering read-only safety, the description fully covers what the tool returns (assets and regime). No gaps 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?

The input schema has 0 parameters, so baseline is 4. The description does not need to add parameter info as there are none.

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 'live macro snapshot' and lists specific assets (DXY, US10Y yield, S&P 500, gold, VIX, BTC dominance, etc.) plus a regime classification, making it distinct from siblings like get_basic_macro or get_market_context.

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 such as get_basic_macro or get_macro_liquidity. The description does not mention when not to use it or provide any contextual 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 readOnlyHint and openWorldHint. The description adds valuable context on the specific data sources (Farside, Etherscan) and the interpretation rule, which goes beyond annotations. However, it omits details like update frequency or data latency.

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 fluff. Every word adds value: the purpose, data sources, and interpretation are front-loaded. Ideal conciseness.

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 parameterless read-only tool, the description provides sufficient context: what it measures, data sources, and signal interpretation. It is complete enough for an AI agent to decide when to invoke it, though it could mention data freshness or update schedule.

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 and 100% coverage by the schema (empty). Baseline is 4 per calibration rules. The description does not need to explain parameters, and it adds no further parameter info.

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 defines the tool as a fiat-to-crypto liquidity gauge, specifying data sources (BTC/ETH ETF flows, USDT/USDC mint/burn) and the bullish interpretation of net inflow. This distinguishes it from siblings like get_basic_macro or get_cex_outflows.

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 assessing liquidity's impact on risk assets ('Net inflow = bullish'), but does not explicitly state when to choose this tool over alternatives like get_basic_macro or get_cex_outflows. No formal exclusions or when-not-to-use 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 read-only and open-world nature; description adds that it combines three distinct data types and returns all matching results, with no contradiction to 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, front-loaded with purpose, no fluff. 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 snapshot tool with one parameter and no output schema, description adequately explains inputs and scope, though output format is not detailed.

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 covers query parameter with examples; description reinforces same meaning without adding new semantics, so baseline score for high coverage applies.

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

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

Description clearly states it provides a unified intelligence snapshot combining Polymarket, HIP-4 prediction markets, and Hyperliquid perp data for any query, distinguishing it from sibling tools that only cover individual data sources.

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 explicitly notes it replaces 3+ separate lookups, implying use for broad overviews, but does not list specific sibling alternatives 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?

Discloses it combines multiple market factors (BTC trend, realized vol, Deribit IV premium, etc.) into a single call. Annotations already declare readOnlyHint and openWorldHint; the description enriches with specific inputs and outputs 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?

Two tightly scoped sentences: the first defines the classifier and outputs, the second lists components and gives usage instruction. No wasted words; all information is relevant and front-loaded.

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

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

Given zero parameters and no output schema, the description fully explains the tool's purpose, output categories, underlying data sources, and recommended invocation order. No gaps remain for an agent to misunderstand.

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 (input schema empty), so the description appropriately focuses on the tool's function and outputs. With zero parameters, a baseline of 4 is applied as per rubric guidelines.

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?

Clearly identifies itself as a 'market regime classifier' and lists five distinct output regimes (RISK_ON_TRENDING, etc.). Distinguishes from the many sibling 'get_*' tools by being a composite classification tool, not a raw data endpoint.

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

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

Explicitly instructs to 'Call this FIRST each session to condition strategy choice,' providing clear usage context. Does not explicitly list when not to use or alternatives, but the primary guidance is strong and actionable.

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 openWorldHint, so the description's mention of live data and specific fields adds useful context without contradicting annotations. It does not disclose auth or rate limits, but these are not expected given tool nature.

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

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

The description is a single, well-structured sentence that immediately conveys purpose, sources, sorting, and output fields. No 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?

Given no output schema, the description adequately outlines return fields (title, prices, volume, expiry). It could mention sorting direction (implicitly descending) but is otherwise complete for a simple list tool.

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

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

Schema coverage is 100% with clear descriptions for all 3 parameters. The description adds 'sorted by volume' which is not in schema, but this is minor. Baseline 3 is appropriate.

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

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

The description clearly states it retrieves live prediction markets from specific sources (Polymarket/HIP-4), sorted by volume, and lists the returned fields. This distinguishes it from siblings like search_markets or get_markets_near_resolution.

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 fetching current markets sorted by volume but does not explicitly state when to use it versus alternatives like search_markets or get_movers. No when-not-to-use 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 read-only and open-world behavior. The description adds context about time and probability filtering, which is consistent. However, it does not explain the open-world aspect further or detail any side effects (none expected).

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 front-loaded with the core function ('Polymarket markets resolving...') and includes usage context. Extremely concise 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?

The description adequately explains the filtering criteria but does not describe the output structure (e.g., which market fields are returned). Since there is no output schema, more detail would improve completeness. However, the tool's purpose is simple and likely consistent with other tools on the server.

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

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

Schema coverage is 100% with adequate descriptions for both parameters. The description adds no new parameter semantics beyond paraphrasing the schema, so baseline score of 3 is appropriate.

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

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

Description clearly states it retrieves Polymarket markets resolving within a time window with high probability, and explicitly mentions use cases (resolution arbitrage, last-minute positioning), effectively distinguishing it from sibling tools like get_markets or get_late_game_sports.

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 provides context of when to use the tool ('resolution arbitrage and last-minute positioning') but does not explicitly state when not to use it or point to alternative tools, leaving some ambiguity.

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

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

Annotations indicate readOnlyHint and openWorldHint, and the description adds context about covering Polymarket and HIP-4 markets. However, it does not disclose data freshness, pagination details, or whether results are based on a specific time window.

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

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose and scope 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?

For a simple list tool with one parameter and no output schema, the description adequately explains what is returned (top markets ranked by metrics). It could mention typical fields in the output but is sufficient overall.

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

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

Schema coverage is 100% and the single parameter 'limit' is fully described in the schema. The description adds no additional semantic 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 specifies the tool retrieves top prediction markets ranked by 24h volume spike or YES/NO price swing, clearly distinguishing it from sibling tools like get_volume_spikes or get_odds.

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 finding breaking news bets and momentum plays, but does not explicitly state when to use this tool over alternatives like get_markets or get_signals. No when-not-to-use 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 declare readOnlyHint=true and openWorldHint=true. The description adds context by specifying news sources (CoinDesk, The Block, Decrypt, Cointelegraph) and the time window (1h price move), which are beyond what annotations provide. No contradictions.

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

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

Two sentences with no wasted words. The first sentence explains the core function and data sources; the second hints at usage. Well-structured and 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?

Despite no output schema, the description covers what the tool returns (headlines + price moves) and sources. It lacks details on result format or pagination but is sufficient for agent decision-making.

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

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

Schema description coverage is 100%, with both parameters asset and hours_back having descriptions. The description adds no new parameter semantics beyond confirming the asset and time range. Baseline of 3 is appropriate.

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

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

The description explicitly states the tool provides 'recent crypto news headlines mentioning an asset... paired with the 1h price move that followed each.' It clearly describes the resource (news correlation) and distinguishes itself from siblings like get_recent_news by adding the price move 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 phrase 'Lets agents filter news bias' indicates usage for assessing news-driven price impact. While it doesn't explicitly list when-not-to-use or alternatives, the purpose is clear enough that agents can infer appropriate contexts, such as analyzing recent market reactions to news.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description's claim of retrieving 'current' prices adds minimal behavioral context. No mention of rate limits, data freshness, or other traits 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?

Single, front-loaded sentence with no wasted words. Clearly communicates the tool's function without unnecessary detail.

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 and two parameters, the description adequately conveys what it returns (prices and probability). No output schema exists, but the description gives sufficient context for an agent to understand 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?

Input schema has 100% description coverage for its two parameters (platform and identifier). The description repeats the platform options but does not add meaning beyond the schema's own 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 the tool retrieves current YES/NO prices and implied probability for Polymarket or HIP-4 market tokens. It uses a specific verb (get) and resource (odds/prices), distinguishing it from sibling tools that focus on funding rates, liquidation clusters, etc.

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 (e.g., get_markets, get_orderbook). While the purpose is clear, the description does not mention exclusions or contexts where other tools would be more appropriate.

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

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

Annotations already include readOnlyHint=true and openWorldHint=true, indicating safe read behavior and that not all coins may be tracked. The description adds the behavioral detail that it uses 'continuous snapshots' and lists the specific regime classifications, which enriches understanding 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?

Two sentences that are front-loaded with the core outcome and examples, then provide contextual uniqueness. Every word serves a purpose without 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?

Despite lacking an output schema, the description lists the four possible regime outputs, giving the agent a clear idea of what to expect. It also explains the unique data source. For a 2-parameter tool with simple output, this is sufficiently complete.

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

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

Schema coverage is 100% with clear descriptions for both parameters (coin: optional, omit to scan all; hours: lookback window). The description reiterates these uses ('Scan all tracked coins or analyze one') but adds no new semantic information beyond the schema, meeting the baseline.

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

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

The description clearly states the tool returns 'Price-vs-OI regime per coin' with specific named regimes (NEW_LONGS, SHORT_SQUEEZE, etc.) and mentions scanning all coins or analyzing one. This distinguishes it from siblings like get_oi_history, which likely returns raw OI data rather than regime classification.

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 when needing the price-vs-OI regime and highlights that the data is unique ('Impossible without OI history...only predmcp records it'), suggesting this is the definitive tool for this analysis. It does not explicitly state when not to use it or directly compare to alternatives, but the unique data claim provides 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?

Disclosures beyond annotations: data source uniqueness (only on predmcp), collection interval (5-min), and inclusion of price+funding. Consistent with readOnlyHint and openWorldHint.

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

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

Three concise sentences, front-loaded with key information, 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?

Given simplicity (2 params, no output schema, annotations present), description fully covers purpose, data source, time window, included fields, and sibling reference.

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

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

Schema coverage is 100%; description does not add new meaning beyond schema definitions for coin and hours. Baseline score applies.

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

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

Description clearly states it returns open-interest time series for a coin over the last 24h from a continuous 5-min collector. Distinguishes from sibling get_oi_divergence and notes uniqueness of data source (only on predmcp, not on Hyperliquid).

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?

Mentions sibling tool for regime classification, implying when to use this vs that. Lacks explicit when-not-to-use but provides clear functional 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 declare readOnlyHint and openWorldHint. Description adds value by explaining the business logic (new long positions cannot be opened), going beyond the structured 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?

Two concise sentences: first states functionality, second gives explicit usage guidance. 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?

Given no output schema and no parameters, description provides sufficient context for a read-only list tool. Could hint at output format but not essential.

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 schema coverage is 100%. Baseline score of 4 is appropriate as description does not need to compensate.

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

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

Description clearly states the tool lists Hyperliquid perps at open interest cap, with a specific verb 'Lists' and defined resource. It differentiates from siblings like get_open_interest by focusing on cap status.

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 states 'Use as a blacklist to avoid getting rejected on entry,' providing clear when-to-use context. Does not name alternatives but implies difference from general OI 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 indicate readOnlyHint and openWorldHint. The description adds context: free Deribit feed, specific metrics, and the behavioral implication (public, real-time data). 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: first lists tool's output, second provides interpretative guidance. Every word carries weight, no fluff. Front-loaded with key 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?

With a single parameter and no output schema, the description fully covers purpose, source, data points, and usage guidance. An agent can reliably decide to call this tool and understand its 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 100% for the single parameter 'asset' with enum and description. The description reinforces that only BTC and ETH are supported via Deribit, but adds no additional detail beyond the schema's own 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 the tool provides a snapshot of BTC or ETH options via Deribit, listing specific metrics (ATM IV, skew, term structure, OI, volume). It is a specific verb+resource combo and distinguishes from siblings like 'get_simple_iv' by including multiple dimensions.

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

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

The description explicitly frames the tool as a sentiment gauge, explaining how to interpret high IV and skew. While it does not mention when not to use it or alternatives, the context of usage is clear and actionable.

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 openWorldHint. Description adds behavioral detail: 'Shows liquidity at each price level', which is consistent and non-contradictory.

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

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

Two sentences, front-loaded with key information, no wasted words. Every sentence adds value.

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

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

Given low complexity (1 param, no output schema, simple read operation), the description fully specifies the tool's purpose and behavior. No 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 covers 100% of the single parameter with a clear description. Description adds no further parameter detail beyond the schema, baseline 3 is appropriate.

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

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

The description clearly states it returns full orderbook depth (bids and asks) for Polymarket market tokens, specifying 'liquidity at each price level'. This distinguishes it from sibling tools like get_markets or get_odds.

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 (e.g., get_markets, get_odds). The description implies it's for orderbook data but doesn't exclude or compare.

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

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

Annotations already indicate readOnlyHint=true, and the description adds detailed behavioral context: it returns cumulative depth at specific USDC tiers and estimated slippage for a given order size. It also warns about slippage destruction in low-liquidity markets, exceeding 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 two sentences, front-loaded with purpose, then return details and a use case clue. Every word adds value; 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?

Given no output schema, the description lists key return fields (top of book, spread, depth tiers, slippage), which is mostly sufficient. However, it does not explain output format or edge cases (e.g., insufficient liquidity), leaving minor ambiguity for a tool with 3 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?

Schema description coverage is 100%, so baseline is 3. The description mentions 'slippage estimate for a given order size', which ties to the size_usdc parameter, but does not add new meaning beyond the 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?

The description clearly states it retrieves 'full orderbook depth + slippage estimate' for 'any Hyperliquid perp or HIP-4 market'. It lists specific return fields (top of book, spread, cumulative depth tiers, estimated slippage), distinguishing it from the simpler sibling 'get_orderbook' by focusing on slippage and depth 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 implies usage for 'HIP-4 farming and low-liquidity assets where market orders get destroyed by slippage', suggesting it's ideal for slippage-sensitive scenarios. However, it does not explicitly name alternatives or provide when-not-to-use guidance, which would make it 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 indicate readOnlyHint and openWorldHint. The description adds behavioral context by explaining the type of divergence (e.g., PM bullish vs HL crowded longs) and noting the computational difficulty. 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?

Three sentences that efficiently state the main purpose, provide an illustrative example, and note the tool's value. No redundancy or 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?

The description explains the concept well but does not specify output structure (no output schema). Given the clear concept and limit parameter, it is sufficiently complete for an agent to understand the tool's role.

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?

Input schema covers both parameters with good descriptions (100% coverage). The tool description adds no additional parameter meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly identifies the tool's purpose: finding markets where Polymarket implied probability diverges from Hyperliquid perpetual funding direction. It provides a concrete example and distinguishes its specific signal from sibling tools like get_funding_outliers or get_hl_funding_pm_correlation.

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 when seeking divergences that are hard to compute manually, but does not explicitly state when not to use or name alternatives. The sibling list makes differentiation possible.

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, and the description adds meaningful context: it uses 14 days of 1-hour Hyperliquid candles and computes specific risk metrics. No contradictions, and the description adds value beyond annotations by detailing the analytics performed.

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

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

Two sentences, front-loaded with the main purpose, followed by specific metrics and data source. No redundant 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 single-parameter tool with no output schema, the description fully informs the agent about what metrics are returned and the data source. It is complete given the tool's simplicity and annotations.

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

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

Schema coverage is 100% with a clear description for the 'positions' parameter in the schema. The description does not add extra meaning about the parameter beyond what the schema already provides, so baseline 3 applies.

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

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

The description clearly states it provides risk analytics for a list of positions, listing specific metrics (beta, sector concentration, correlation, volatility, VaR) and data source. It distinguishes from siblings like 'get_funding_rates' or 'get_conviction_score' 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?

The description implies use for risk analysis but does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance or mention other tools that might be more appropriate for specific needs.

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

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

Adds behavioral context beyond annotations: warns when liquidation sits inside stop, caps size by orderbook liquidity, and computes carry cost. This complements readOnlyHint and openWorldHint annotations, providing useful safety and dependency information.

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 core purpose, no unnecessary words. Every sentence adds value, making it efficient and easy to scan.

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

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

For a tool with 8 parameters and no output schema, the description covers the core computation, typical workflow, and a warning scenario. It could list key outputs, but the warning and prerequisites make it 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 covers all parameters with descriptions, defaults, and ranges. The description contextualizes parameters by mentioning how they interrelate (e.g., max_slippage_pct relates to orderbook depth) and suggests grounding win_rate_pct, adding 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 it computes a concrete position from signal and bankroll, listing specific components (fractional-Kelly, liquidity cap, ATR stop, liquidation, funding cost, risk). It distinguishes itself from sibling data-retrieval tools by focusing on position sizing.

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 advises grounding win_rate_pct with sibling tools get_signal_performance or get_signal_backtest, indicating a prerequisite. While it implies this is the tool for position sizing after a signal, it could more explicitly state when to use it versus other 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, so the description adds value by explaining the computation: 'Computed from 30d of HL hourly candles'. This provides 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?

Two sentences with no wasted words. Front-loaded with purpose and bullet-like list of outputs. Excellent conciseness.

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 parameter and no output schema, the description is complete. It specifies inputs, outputs, and computational basis. No 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 100% and the parameter description in the schema already clearly defines 'asset'. The tool description does not add further detail about the parameter, so baseline 3 is appropriate.

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

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

The description clearly states it's a 'one-call snapshot for an asset' listing specific metrics (mark price, returns, high/low, drawdown, rally, volatility). This distinguishes it from siblings like get_markets or get_funding_rates which focus on different data.

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

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

The description implies usage for a quick price summary but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. Agents must infer from the listed metrics.

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 openWorldHint=true, so the description's addition of specific RSS sources and the Pro feature adds some context. However, it does not disclose details like rate limits, caching behavior, or what 'Pro' entails in terms of access or cost.

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-loads the core purpose, and includes the optional Pro feature efficiently. Every sentence adds value without unnecessary 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?

While the description covers the basic functionality, it lacks details on return format, error handling, pagination, or what happens when no headlines are found. For an agent evaluating this tool, more completeness about the output would be helpful.

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 100% parameter description coverage, so the description does not need to add much. It does not explain parameter semantics beyond what the schema already provides, meeting the baseline expectation.

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

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

The description clearly states that the tool retrieves recent crypto news headlines for a specific asset ticker from four named RSS feeds, and distinguishes a Pro feature. This is a specific verb-resource combination that differentiates it from sibling tools like get_news_correlation.

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 for getting headlines matching an asset ticker, but provides no explicit guidance on when to use this tool versus alternatives, or when not to use it. Sibling tools like get_news_correlation exist, but no comparison is made.

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

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

Discloses cursor-based polling (pass next_cursor as since_id) and free tier cap (20), adding beyond annotations that mark it as read-only and open-world.

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 concise sentences: purpose, polling mechanism, alternative tool. No superfluous text.

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 only 3 parameters, description fully covers what an agent needs to use the tool correctly, including comparison with sibling.

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 covers all parameters fully; description adds value by explaining cursor usage for since_id and limit cap, but coin parameter lacks extra context.

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 specifies exactly what events (funding outliers, whale trades, OI caps) and timeframe (last hour), distinguishing it from sibling get_signal_history.

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 states it is the polling equivalent of SSE stream, and compares with get_signal_history for 7-day history, providing clear when-to-use 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?

Discloses it is a read-only evaluation (consistent with readOnlyHint annotation) and explains the components of the score (spread, slippage, depth, etc.), adding 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?

Three concise, front-loaded sentences with no wasted words. The purpose and key differentiator are stated immediately.

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?

Though no output schema, description specifies output as a score (0-100, A-F grade) and lists evaluation factors, making it complete for an agent to understand what it 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?

Schema coverage is 100%, so description adds little beyond schema. It mentions size_usdc is for evaluating slippage, which matches schema description. No significant new meaning.

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

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

Clearly states it provides an execution-quality score (0-100, A-F grade) for entering a position, listing specific factors like spread, slippage, depth. Explicitly differentiates from conviction scoring, distinguishing 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?

Implicitly guides when to use by contrasting with conviction score ('Different from conviction — this scores ENTRY conditions'), hinting at alternatives. Could be more explicit about when not to use, but sufficient.

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 openWorldHint=true, so the description adds value by detailing that it computes forward returns, win rate, and Sharpe. It also mentions clustering triggers with min_separation_hours. No contradictions; the description enriches understanding of the tool's behavior.

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

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

Two sentences: the first packs core functionality (what, how, outputs), the second emphasizes value. No filler, perfectly front-loaded. Every sentence 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?

With 6 parameters and no output schema, the description adequately covers purpose and behavior. It explains the signal types and clustering but could detail output format. However, given the tool's complexity, the description is fairly complete and allows an agent to understand its 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?

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining that 'last N days' corresponds to lookback_days and that forward returns include 1h/4h/24h windows, which are not in the schema. It also mentions win rate and Sharpe as outputs, helping users interpret results.

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 finds historical instances of a signal type on an asset over N days and computes forward returns, win rate, and Sharpe. This distinguishes it from siblings like get_signals (which merely lists signals) and get_funding_rates (raw data). The verb 'find' and 'compute' are specific, and the resource is a backtested signal.

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 'Lets an agent reason about EV before trading,' implying the tool is for evaluating signal quality prior to trades. It does not explicitly state when not to use or provide alternatives, but the context of sibling tools allows inference. A more explicit exclusion would push to 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 indicate readOnly and openWorld hints. The description adds cursor-based pagination and the join with forward returns upon maturity, which are not in 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?

Two sentences plus a question, no fluff. Front-loads the main purpose and examples. Every sentence adds value.

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

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

The description explains what is returned (signals with forward returns) and pagination. Without an output schema, it carries the full burden. It could define 'mature' more explicitly 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?

Schema covers 100% of parameters with descriptions. The description adds context like cursor usage (since_id) and the max lookback window (7 days), and mentions signal_types examples. This adds value 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 retrieves server-detected signal events over up to 7 days, each joined with forward returns. It uses the verb 'get' and specific resource 'signal history', and the motivating question distinguishes it from siblings like get_recent_signals or get_signal_backtest.

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

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

The description provides a concrete usage scenario via the question, implying when to use this tool (historical analysis with forward returns). However, it does not explicitly exclude other contexts or compare to siblings like get_signal_backtest.

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 it as read-only and open-world. The description adds important context about the data source ('measured on OUR actually-emitted production signals (not a backtest reconstruction)') and sample size caution, enhancing transparency 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?

Two sentences, no wasted words. The core purpose and key usage caveat are front-loaded. Every sentence adds value.

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

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

For a tool with no output schema, the description explains the return values (hit rates, average forward returns, sample sizes) and provides usage guidance. It is almost complete, though missing explicit mention of the output structure per signal type.

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

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

Schema coverage is 100%, so the schema already documents parameter meanings. The description does not add new parameter-level details but reinforces usage context. Baseline 3 is appropriate.

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

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

The description clearly states the tool provides 'Hit rates and average forward returns per signal type' and distinguishes it from backtest reconstructions ('OUR actually-emitted production signals'). This separates it from sibling tools like get_signal_backtest.

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 suggests using this tool to 'ground win_rate inputs for get_position_size' and warns about sample sizes ('treat n < 10 as anecdotal'). While it doesn't list when not to use it, the guidance is clear and actionable.

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 and openWorldHint. The description adds concrete output types (BULLISH/BEARISH/DIVERGENCE) and mentions reasoning, which is helpful 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?

Two sentences, no wasted words. Key information is front-loaded: purpose then output format. Highly 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 no output schema, the description should fully describe return format. It mentions signal type and reasoning but lacks structure (e.g., JSON fields). For a simple tool, it is adequate but not detailed.

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

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

Schema coverage is 100% with a clear description for the 'coin' parameter. The description adds example tickers but no new semantic detail, so baseline 3 applies.

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

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

The description clearly states the tool detects divergence signals between two specific data sources (Hyperliquid perpetual funding/OI sentiment and HIP-4 prediction market odds) and specifies output types (BULLISH/BEARISH/DIVERGENCE). This distinguishes it from siblings like get_pm_hl_divergences by naming both sources.

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 what the tool returns but does not explicitly state when to use it versus alternative tools (e.g., get_pm_hl_divergences). The example provides context, but no direct guidance on 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 indicate readOnlyHint=true, so the read-only nature is clear. The description adds context (Deribit public feed, free, snapshot) but does not disclose additional behavioral traits like update frequency or limits.

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

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

The description is two concise sentences—first sentence covers core purpose, second contrasts with a Pro version. No superfluous 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 one-parameter tool with no output schema, the description adequately explains the source and data included. It could be more complete by explicitly linking to the sibling Pro tool (get_options_iv) for advanced needs.

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 100% coverage for the single asset parameter, and the description merely reiterates the enum values without adding new semantic meaning beyond the schema.

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

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

The description clearly states it provides a 'BTC or ETH options snapshot' with specific data fields (ATM implied volatility, total OI, 24h volume), and distinguishes itself from a 'Pro' version that adds skew and term structure.

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

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

The description implies when to use this tool (simple snapshot) versus the 'Pro' version, but does not explicitly name the sibling tool (e.g., get_options_iv) or provide when-not-to-use 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 mark as readOnly and openWorld, so safety is clear. Description adds that results include OI and annualized yield, and are ranked by absolute funding rate, which is useful behavioral context 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?

Two sentences, no filler. Front-loaded with the key action and output, then a concise usage cue. 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?

No output schema exists, but the description mentions the key fields (OI, annualized yield) and ranking, which is sufficient for a simple list-of-items tool. Could be more explicit about the structure, but adequate given low 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?

Input schema covers both parameters with descriptions, achieving 100% coverage. The description does not add any additional meaning beyond what is already in the schema, so baseline 3 is appropriate.

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

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

Description clearly states it returns top Hyperliquid perps ranked by absolute funding rate, with OI and annualized yield. It distinguishes from sibling tools like get_funding_rates by specifying 'top' and the ranking criterion.

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

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

States usefulness for finding overcrowded longs/shorts and carry opportunities, providing clear use context. Does not explicitly exclude alternatives, but the specificity is adequate.

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 provide readOnlyHint=true and openWorldHint=true, establishing safe read behavior and variable data. The description adds context about data sources (Tally + curated DB) and specific event types, but does not disclose additional behavioral traits like rate limits or data completeness. This adds some value without overstepping.

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 defines what the tool does, second states its purpose and data provenance. No wasted words, every sentence contributes value. Ideal length for quick comprehension.

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 2 parameters, high schema coverage, and informative annotations, the description covers the essential behavioral context (types of events, data sources). The lack of output schema is mitigated by the clear implication that a list of catalysts is returned. Minor gap: no mention of empty results, but openWorldHint covers variability.

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

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

Schema coverage is 100% with clear descriptions for both parameters (asset and horizon_hours). The description's phrase 'for an asset within a horizon' maps to these parameters but does not add new semantic meaning or examples beyond the schema. Baseline 3 is appropriate.

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

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

Description uses specific verb 'Lists' and resource 'upcoming market catalysts for an asset within a horizon', enumerating concrete examples (token unlocks, governance votes, ETF/SEC deadlines, FOMC dates). This clearly distinguishes it from sibling tools like get_market_context or get_price_summary that provide different types of information.

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

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

The statement 'Helps agents avoid blind trades into known events' implies a use case, but no explicit when-to-use or when-not-to-use guidance is given. There is no mention of alternatives among the many sibling tools, so the agent must infer context.

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

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

Annotations indicate readOnlyHint=true and openWorldHint=true, which the description complements by explaining the rationale behind volume spikes (e.g., preceding news). It adds behavioral context beyond annotations, though it does not detail the return format.

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

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

Two sentences with no wasted words. The first sentence states the function, the second adds significance. Front-loaded and efficient.

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

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

For a simple tool with 2 parameters, annotations, and no output schema, the description is sufficiently clear about purpose and usage context. It could mention the return structure, but it is not essential.

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?

Input schema has 100% description coverage with clear explanations for 'limit' and 'min_ratio'. The description adds no additional parameter details, so baseline 3 is appropriate.

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

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

The description uses specific verb 'get' and resource 'volume spikes', clearly stating it returns Polymarket markets with abnormal 24h volume vs 7-day average. This distinguishes it from sibling tools like get_movers or get_markets.

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

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

It provides context that volume spikes typically precede news events or informed positioning, indicating when to use the tool. However, it does not explicitly mention when not to use it or name alternative 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 and openWorldHint=true, which minimize the need for behavioral disclosure. The description adds value by specifying the data source's durability and restart-proof nature, as well as the return format. 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, front-loading the core purpose and key differentiators. Every sentence 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?

Given the tool's complexity (3 params, no output schema), the description adequately covers return values and provides context about the tape floor and duration. It lacks explicit detail on 'largest recent prints' 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 coverage is 100% with each parameter described (coin, hours, min_notional_usdc). The description provides no additional param-specific meaning beyond what the schema already states, so it meets the baseline expectation.

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 cumulative whale buy/sell imbalance over hours-to-days, distinguishing it from get_whale_trades by mentioning longer horizons. It specifies the input (durable trade tape ≥$25k) and outputs (imbalance ratio, verdict, largest prints), making the purpose unambiguous.

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

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

The description implies when to use this tool ('Longer horizons than get_whale_trades (1h buffer)'), providing context for choosing between siblings. However, it doesn't explicitly state when not to use it or provide alternative selection criteria.

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 openWorldHint=false. Description adds valuable context: the database is curated, includes specific categories, and helps distinguish machine-like activity from alpha-generating. It does not contradict annotations and provides clarity beyond what structured fields offer.

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 action and resource, then purpose. No redundant information. Every sentence 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?

Description implies the tool returns a label but does not explicitly state output format (e.g., string, object). With no output schema, this is a minor gap. Adequate but could be improved by specifying return type.

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 describes the parameter thoroughly (0x-prefixed, 40 hex chars) and coverage is 100%. The description adds no new parameter details beyond restating 'address', so score is at baseline 3.

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

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

Description clearly states it 'look up an Ethereum address against our curated label DB', listing specific label types (CEX hot wallets, market makers, suspected funds) and explaining the purpose (distinguish mechanical MM flow from alpha-generating activity). The tool is distinct from siblings which focus on market data, funding rates, etc.

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 implies usage for identifying known addresses but does not explicitly state when to use versus alternatives, nor does it provide exclusion criteria. It gives context but lacks explicit guidance on when-not or alternatives among the many 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 and openWorldHint=true. Description adds that a user is required, optional market filter, and default min_size_usdc of 1000. This adds value but does not conflict with annotations. No additional behavioral traits disclosed beyond what annotations imply.

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 fluff. All information is front-loaded and every word is substantive.

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 readOnlyHint and openWorldHint, the description sufficiently covers purpose and constraints. Missing explanation of output format, but for a simple retrieval tool without output schema, 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?

Schema coverage is 100%, so baseline is 3. Description adds context: why 'user' is required (no public endpoint), and explains the default for min_size_usdc. This goes beyond 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?

Clear verb ('get') and resource ('whale positions') with specific scope ('a specific Polymarket wallet, optionally filtered to one market'). Distinguishes from sibling tools like get_whale_flow, get_whale_trades, etc.

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?

Explains that the API requires a specific user (no public endpoint) and instructs to pass the wallet address. Provides clear context but does not explicitly state when not to use or compare 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 already declare readOnlyHint=true and openWorldHint=true. Description adds that it returns recent trades with side/size/price/timestamp, consistent with read-only behavior. No additional behavioral insight like rate limits or data freshness.

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

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

Two sentences, front-loaded with purpose and output details. No 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?

Adequately describes purpose, input, and output for a simple retrieval tool. Slightly lacking in data freshness or pagination details, but acceptable given 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?

Schema covers both parameters (coin, min_notional_usdc) with descriptions. The description mentions 'above a notional threshold' but adds no new semantics beyond schema defaults and examples.

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?

Clearly states it retrieves recent large trades on Hyperliquid perps with a notional threshold, listing output fields (side, size, price, timestamp). Distinguishes from siblings like get_whale_positions.

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?

Implies usage for fetching recent large trades for a coin but lacks explicit guidance on when to use vs. alternatives (e.g., get_whale_convergence) or when not 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 indicate read-only and open-world hints. The description adds that results are ranked with current odds, providing behavioral 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?

Two sentences, no redundancy. First sentence captures core purpose, second adds result characteristics.

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

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

With 2 fully described parameters and no output schema, the description adequately explains the search scope and result type. Could mention that it searches names and descriptions, but schema covers that.

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 already describes both parameters with 100% coverage. The description adds example queries, enhancing meaning slightly but not substantially.

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 performs full-text search across Polymarket and HIP-4 prediction markets and returns ranked results with current odds, distinguishing it from sibling tools like 'get_markets'.

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

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

No explicit guidance on when to use this tool versus alternatives. The description implies use for full-text search, but does not mention exclusions or alternative tools.

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