AgentFeed

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

With no annotations present, the description carries the full burden of disclosure. It goes beyond the name by revealing the paid nature of the call, the payment transport (x402, Solana mainnet), and the returned metric family. It does not mention auth or rate limits, but the cost and network context are meaningful behavioral disclosures.

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 filler. The core purpose is front-loaded, the output metrics are compactly listed, and the cost/payment detail is included without bloating the description. 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?

For a single-parameter tool with no output schema and no annotations, the description covers the essential context: what is measured, what is returned, and what it costs. It could name a concrete example response shape, but the listed metrics (premium/discount %, contango/backwardation, funding context) give enough for an agent to invoke and interpret the result.

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

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

Schema coverage is 100%, so the symbol parameter is already documented. The description adds useful context by clarifying that the symbol is a USDT perp pair and that the tool computes perp-vs-spot basis, which helps disambiguate the parameter. This is marginal value above the schema, so a 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 a specific verb and resource: 'Perp-vs-spot basis for any USDT pair.' It lists concrete outputs (premium/discount %, contango/backwardation read, funding context), which clearly distinguishes it from sibling tools like get_funding_rate or get_spread_arb. The tool's function is immediately identifiable without needing to inspect the schema.

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

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

The phrase 'for any USDT pair' gives clear scope for when to call it, and the cost note ('Costs $0.01 USDC per call') is an important practical constraint. It does not explicitly mention alternatives or exclusions, but the purpose is specific enough that an agent can infer when basis data is needed.

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

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

Without annotations, the description carries the full burden and it delivers. It discloses multi-source aggregation, Pyth Hermes fallback, null semantics for confidence and publish_time on Coinbase/Kraken, and the per-call cost — all substantive behavioral context beyond the name and empty schema.

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

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

Two sentences front-load the core purpose and then pack the caveats — sources, fallback, null fields, and cost — without waste. Every clause adds information an agent needs.

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, and the description covers purpose, data sources, fallback behavior, null field behavior, and cost. It does not specify the exact main price field name or full response shape, but with no output schema and zero parameters it is still substantially 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?

There are zero parameters and the schema already documents them completely, so no parameter explanation is needed. The baseline for a 0-parameter tool is 4, and the description appropriately focuses elsewhere.

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

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

The description opens with a specific verb and resource: 'Live BTC/USD spot price,' which clearly identifies the tool's purpose. It does not explicitly differentiate from sibling price tools like pricing or get_sol_price, but the resource is 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 word 'Live' implies use when a current BTC/USD quote is needed, and the fallback note suggests reliability expectations. It does not name sibling alternatives or state when not to use it, so guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full transparency burden and does well by disclosing cost ('Costs $0.01 USDC per call'), the empty-cascades behavior, and the narrow asset/exchange scope. It doesn't mention error handling, rate limits, or exactly how x402 payment is executed, but the disclosed operational traits are substantial.

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, each serving a clear purpose: the first defines the tool and its outputs, the second clarifies empty results, and the third gives the alternative and cost. Information is front-loaded with the core purpose, and there is no filler.

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

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

Given no output schema and no annotations, the description covers the essentials: return payload, empty-array semantics, cost, and scope. The main omissions are the meaning of severity thresholds and how to interpret the cascade clustering, but the description is complete enough for an agent to select and call the tool correctly.

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

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

The input schema already documents all three optional parameters with descriptions and defaults, giving 100% coverage. The description does not add new parameter-level meaning; it only refers to output fields like USD total and prints, which relate to min_usd and min_events only indirectly.

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

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

The description states a specific action and resource: it detects liquidation cascades for exactly SOL, BTC, ETH, XRP, and DOGE, and lists the returned fields (symbol, side, USD total, prints, duration, severity). It also distinguishes itself from sibling get_cascade_scan by explicitly limiting scope to the 5 majors.

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

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

It explicitly names the alternative and the condition that selects it: 'For all ~600 USDT perps across 3 exchanges, use get_cascade_scan.' Additionally, 'active NOW' implies this tool is for current real-time detection, separating it from history/forecast siblings.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It explains the calibration source, why the data cannot be reconstructed, what each answer includes, the decline-when-uncertain behavior, and the exact cost and payment rail. This is exemplary transparency.

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

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

The first sentence front-loads the core purpose, and every subsequent sentence adds a distinct operational fact: definition, calibration provenance, response contents, failure behavior, and cost. There is no filler or repetition.

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

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

There is no output schema, so the description must convey what the caller gets. It does: probability, threshold, window, historical occurrences, settling instructions, and decline behavior. Combined with fully documented optional parameters, nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents symbol, symbols, defaults, and batch limits. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: it returns a forward-looking probability of liquidation in the next 15 minutes exceeding a symbol's own 90th-percentile window. It explicitly disclaims being a historical description, which differentiates it from history-oriented siblings. This is clear and distinct.

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 establishes when to use it: for forward-looking liquidation forecasts rather than historical facts, and notes that it declines when history is insufficient. It does not explicitly name alternatives like get_cascade_forecast_free or get_cascade_history, but the context strongly implies the intended 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?

With no annotations, the description carries the behavioral disclosure burden. It does add useful behavioral context: the tool is free, full-quality, has no delay, and withholds nothing. However, it doesn't describe what the returned forecast looks like, how the output should be interpreted, or how 'calibration' is presented, leaving some behavioral ambiguity.

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

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

The description is short, front-loaded with the free-taster framing, and quickly establishes what the tool does and when to use it. It loses a small amount of efficiency because 'Free' appears twice, once in the opening label and once as a standalone final sentence, making the ending redundant.

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

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

Given the zero-parameter schema and lack of output schema, the description is reasonably complete for selection purposes. However, it never explains what the forecast output contains, its format, or how an agent should consume it after invoking the tool. This is a notable gap because no output schema exists to fill that void.

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

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

The tool has zero parameters, and schema coverage is 100%, so there is no parameter burden to carry. The description effectively communicates the key implicit parameter—the symbol SOL—by naming it explicitly. This matches the baseline for a zero-parameter tool.

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

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

The description clearly states the tool's core purpose: a liquidation forecast for SOL. It also distinguishes itself from siblings by being a free taster, covering only SOL while the paid option covers ~345 symbols. The phrase 'full-quality... no delay and nothing withheld' removes ambiguity about it being a degraded demo.

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

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

It explicitly tells the agent when to use this tool: 'Use it to check the calibration before paying for coverage of the other ~345 symbols.' This implies the alternative is the paid, broader forecast tool, though it doesn't name get_cascade_forecast directly. It provides a clear use case but doesn't fully spell out 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?

With no annotations, the description carries the burden of behavioral disclosure. It reveals that this is a historical read operation, describes the data composition, discloses the cost per call, and mentions the x402/Solana mainnet payment context. It does not describe pagination or exact response formatting, but it adds meaningful behavioral context beyond a bare tool name.

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

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

The description is three sentences with no wasted words. The core meaning is front-loaded, the comparison to the live alert tool is concise, and the cost/payment detail is included without bloating the 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 covers purpose, data elements, time window, and cost, which is strong given the absence of an output schema and annotations. It names the key response fields the agent can expect, though it stops short of documenting the full return shape or exact payment/authorization mechanics.

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 80%, so the schema already documents most parameters. The description adds context about event contents and the 72h lookback window, but it does not meaningfully enrich gap_s, scope, or min_usd beyond what the input schema already states.

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

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

The description states a specific verb and resource: it reconstructs PAST liquidation cascades from the tape and defines them as clustered same-side flush events with start/end, prints, USD total, and peak print. It also distinguishes itself from get_cascade_alert, so an agent can tell it apart from the nearest sibling.

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 contrasts with get_cascade_alert: 'get_cascade_alert tells you NOW; this tells you what already happened, up to 72h back.' This provides clear context for when to choose historical data over live alerts, though it does not cover exclusions relative to other cascade tools like forecast or scan.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the paid nature ($0.05 USDC per call), the exact exchanges and universe, and the returned fields. It does not cover rate limits, auth requirements, or empty-result behavior, but the core behavioral and cost profile is clear.

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 front-loaded sentences, each earning its place: scope, unique coverage rationale, and output/cost. No filler or restatement of the tool name.

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 annotations and no output schema, the description provides enough: universe, exchanges, output fields, price, and parameter defaults via schema. Minor gaps remain around output formatting and behavior when no cascade is detected, but an agent can select and call this tool correctly.

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

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

Schema coverage is 100% (window, min_usd, min_events all have descriptions), so the schema carries parameter meaning and the description does not need to repeat them. It adds no param-level detail, but none is needed.

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

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

States a specific action and resource: a cascade scan detecting liquidation cascades across ~600 USDT perps on Bybit, OKX and Binance. The 'FULL-UNIVERSE' and 'not just majors' framing clearly separates it from narrower liquidation tools, and the listed return fields further anchor its role.

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

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

Gives clear context: this is the full-universe cascade detector for simultaneous multi-exchange coverage, with a unique-data rationale. It does not explicitly name sibling alternatives or state when-not-to-use, so the routing guidance is context-driven rather than explicit.

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

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

With no annotations, the description carries the disclosure burden and reveals the per-call cost ($0.005 USDC), the live/executable nature, and the key outputs. It doesn't explicitly state there are no side effects or rate limits, but for a quote tool the cost and live-execution caveat are the most material behaviors.

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 short sentences with no filler: the function, the key differentiator, and the cost. All information is front-loaded and each clause 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 simple three-parameter tool with no output schema, the description names the important outputs (amount, price impact, route) and the operational cost. It could add a note about quote freshness or response shape, but nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema fully documents the three parameters. The description adds no parameter-level detail, but it doesn't need to because the schema already carries that burden.

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

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

The description opens with 'Live Jupiter swap quote for any SPL pair' naming the exact verb, resource, and scope. It also distinguishes the tool from an index price, which helps separate it from the many pricing-focused 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?

It clearly frames the tool as the source for executable DEX swap prices rather than index/market prices, giving an agent a reason to pick it over price-checking siblings. It does not explicitly name alternatives or state exclusions, but the context is strong.

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

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

There are no annotations, so the description carries the full burden. It discloses important behavioral details: results are 'computed from the tape at request time, nothing hardcoded,' the corroboration rule requires six consecutive consistent observations, and it explains distinctions like router refusal versus an empty book. This is far more transparent than most tool descriptions.

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

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

The description is densely informative but runs as one long paragraph with multiple nested parentheticals and repeats 'FREE' at the beginning and 'Free.' at the end. While it front-loads the core purpose, it would be more agent-friendly as bullet points or shorter sentences.

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

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

For a zero-parameter, no-output-schema informational tool, the description is remarkably complete. It covers what is measured, the corroboration rule, status vocabulary, control design, results, coverage, and cadence, and it explains when to read it relative to get_exit_quote. Nothing essential is missing.

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

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

The input schema is empty with 0 parameters and 100% schema coverage, which gives a baseline of 4. There are no parameters to describe, and the description correctly focuses on what the tool returns rather than inventing parameter guidance.

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

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

The description opens with a specific statement: 'FREE: how overhang measures exit liquidity on lending collateral, and the counts behind every paid answer.' It then enumerates exactly what the tool returns: measurement definition, corroboration rule, status vocabulary, control design, gated sweep, row counts, covered symbols/markets, and cadence. This clearly differentiates it from the paid sibling get_exit_quote.

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

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

The description explicitly tells the agent when to use it: 'Read this before paying for get_exit_quote, and to check the claim rather than trust it.' This names the relevant alternative and provides a clear ordering and use case, so there is no ambiguity about when this tool should be selected.

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

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

With no annotations provided, the description fully carries the burden of behavioral disclosure. It reveals the $0.02 USDC per-call cost, the six-consecutive-observation terminal verdict rule, fallback to the last corroborated measurement instead of null, and the status split between permissioning and actual illiquidity.

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

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

The description is long but dense, with the core purpose front-loaded and each sentence adding a specific detail. Some rhetorical asides, such as the zero-bad-debt caveat, are not strictly needed for invocation but contribute interpretive context. Overall it is structured and not padded.

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

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

For a tool with no output schema, the description enumerates returned metrics, explains behavior around bad quotes and fallback, states the cost, and references the sibling for deeper methodology. An agent has enough information to call the tool correctly and interpret the result.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (symbol and size_usd). The description reinforces that the nearest measured clip is returned and never interpolated, but this is also present in the schema, adding minimal new value.

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

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

The description states the tool measures exit liquidity on seized collateral, contrasting realised liquidation proceeds against the oracle mark price. It names specific returned fields and distinguishes router-refusal from true illiquidity, which clearly separates it from siblings like get_dex_quote or get_exit_method.

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

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

The description gives clear context for when this tool is relevant: assessing what a liquidator actually realises when selling seized Kamino reserves. It explicitly points to get_exit_method for methodology and corroboration rules, though it does not enumerate exclusions or when to prefer a sibling like get_dex_quote.

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

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

With no annotations, the description carries the behavioral disclosure burden. It adds 'Free' and the classification detail, which offer some useful context beyond the name, but it does not mention data source, update frequency, response format, or any rate limits.

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

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

Two short sentences deliver the core value proposition with no filler. The essential range and classification information is front-loaded, and 'Free' is a useful extra 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?

For a zero-parameter getter with no output schema, the description adequately communicates the returned concept (index with classification) and one practical constraint ('Free'). It could mention whether only the current value is returned, but the omission is minor for such a simple 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 tool takes zero parameters, so parameter-level semantics are not needed. The description appropriately focuses on what the value represents rather than input details.

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

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

The description states a specific verb ('get'), a clear resource ('Crypto Fear & Greed index'), and the value range (0-100) with classification. This distinguishes it from the many sibling get_* tools by naming an exact market sentiment metric.

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

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

No guidance is given about when to prefer this tool over alternatives like get_squeeze_score, get_volatility, or get_market_snapshot. The phrase 'Free' hints at a distinguishing characteristic, but there is no explicit when-to-use or when-not-to-use context.

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

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

With no annotations, the description carries the burden of behavioral transparency. It discloses that the tool is free and returns machine-readable content including settlement instructions and symbols, but it does not specify output format, error behavior, or any access constraints.

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

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

The description is short and front-loaded with the key 'FREE' trait. The ending 'Free.' is mildly redundant after the opening 'FREE:', but overall the text is efficient and easy to parse.

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

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

For a zero-parameter tool with no output schema, the description covers what the agent gets: the forecast question, settlement method, and symbol list. It could specify the exact machine-readable format, but the stated contents are sufficient for basic invocation.

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

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

The tool has zero parameters and an empty input schema, so the description has no parameter semantics to compensate for. The default baseline of 4 applies because there is nothing missing in parameter documentation.

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

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

The description clearly states the tool returns the exact question a forecast answers, plus settlement instructions and the covered symbols list. It is distinct from forecast-record tools by emphasizing the question and settlement data, though it does not explicitly name sibling tools.

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

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

The instruction 'Read this before building on the forecast' gives a clear context for when to use the tool. It does not mention exclusions or alternatives, but the timing guidance is actionable and specific.

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

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

With no annotations, the description carries the full transparency burden, and it delivers: it states that forecasts were written before the window opened, settled from the exchange public feed, and that raw rows are returned for independent recomputation. It also explicitly disclaims being a backtest, which is a meaningful behavioral disclosure.

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

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

The description is well front-loaded with 'FREE: the live track record of this miner' and then gives concrete detail about provenance and returned metrics. It is slightly wordy with the repeated 'Free' at the end and the rhetorical backtest contrast, but those sentences still add differentiating 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?

There is no output schema, so the description must communicate what the agent will get back. It lists the key metrics, raw rows, and the settlement methodology, which is enough for an agent to know what this call does and what to expect. It does not describe the exact output envelope or possible error cases, but for a read-only data retrieval tool this is a minor gap.

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

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

The input schema already documents both parameters fully: rows specifies how many raw rows to return, max 500, default 50, and symbol restricts to one symbol. The description adds no parameter-specific semantics beyond reinforcing that raw rows are part of the response, so the schema does the heavy lifting.

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

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

The description clearly identifies the resource: the live track record of this miner, and states exactly what it returns: settled count, base rate, Brier skill, coverage, calibration error, and a reliability curve. It also distinguishes itself from a backtest, which separates it from related forecast/analysis tools.

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

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

The description gives clear context that this is a free, verifiable, live track record rather than a self-computed backtest. It does not name a specific alternative tool, but it does make the when-to-use boundary explicit: anyone who wants an auditable, non-backtest performance record for this miner.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses a critical paid-execution detail: costs $0.01 USDC per call via x402 on Solana mainnet. It also communicates cross-venue aggregation and the surrounding data (spread, crowding). It does not cover failure modes or return shape, but for a simple one-parameter pricing tool, the disclosed traits are sufficient and valuable.

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

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

The description is extremely efficient: two sentences deliver the tool's purpose, venue scope, the alternative to compare against, and the pricing model. Every clause adds information, with the core capability front-loaded.

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

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

For a tool with one parameter, no output schema, and no annotations, the description covers the essential invocation context: symbol scope, venue set, cost, and the sibling alternative. The phrase 'crowding read' could be more explicit, but it does not block correct invocation. Overall, the description is adequately complete for the tool's simplicity.

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

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

The schema describes the single parameter as a USDT perp symbol with an example, giving 100% coverage. The description adds the qualifier 'ANY' and reinforces the acceptable format, but this is already captured in the schema. The description does not need to compensate for missing parameter documentation, so the 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 a specific action: retrieving funding for ANY USDT perp across three named venues (Bybit, OKX, Hyperliquid) in one call, with additional spread and crowding data. It also distinguishes itself from the sibling get_funding_rate by noting that sibling covers only SOL+BTC, making the tool's unique scope obvious.

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 names get_funding_rate as the alternative and states its limitation (SOL+BTC only), which implies when this tool is the better choice. It does not explicitly enumerate exclusion cases, such as when only a single venue is needed, but the scope is clear enough for an agent to select between the two most relevant siblings.

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

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

With no annotations, the description carries the behavioral disclosure burden. It adds meaningful behavioral details: the ~600 USDT perps universe, the annualized funding format, inclusion of 24h price move and OI, and the $0.02 USDC per-call cost on x402/Solana mainnet. This goes well beyond a bare statement of purpose, though it does not cover rate limits or authentication details.

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

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

Three tight sentences: the first explains the product and output fields, the second gives the analytical interpretation, and the third states cost and network. There is no fluff and key information is front-loaded.

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

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

For a read-like data tool with simple optional parameters and no output schema, the description covers the important context: scope, returned metrics, practical interpretation, and cost. An agent has enough information to decide when to invoke it and what to expect.

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 limit and min_turnover_usd both described. The description does not add extra parameter semantics beyond the schema, so the baseline 3 applies.

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

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

The description clearly states what the tool returns: the most positive and most negative funding extremes across ~600 USDT perps, including annualized %, 24h price move, and OI. This distinguishes it from sibling tools like get_funding_rate or get_funding_history, which are about individual funding rates or histories.

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

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

The description provides clear context: it identifies crowded trades and explicitly calls out 'Crowded shorts = squeeze candidates,' signaling when this tool is useful. It does not explicitly name alternative tools or state when not to use it, so it misses the full exclusion guidance.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It transparently reveals the most important non-obvious behavior: the call costs $0.005 USDC via x402 on Solana mainnet. It also clarifies the interval cap. It does not mention failure modes or prerequisites, but the paid external-call behavior is clearly flagged.

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 tight sentences: the first delivers the core function and output metrics, the second delivers cost and payment rail. There is no filler, and the key information is front-loaded.

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

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

For a low-complexity tool with two parameters and no output schema, the description covers the essential output fields, scope, and cost. It could be more complete with explicit return shape or sibling routing, but nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents symbol and limit with format, range, and default. The description mostly restates these constraints ('any USDT perp', 'up to 200 intervals') and adds output context rather than new input semantics, which lands at the 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?

The description states a specific verb and resource: 'Funding-rate history for any USDT perp', and lists the concrete output metrics (average, annualized, share of positive intervals). This clearly distinguishes it from funding-related siblings like get_funding_rate or get_funding_extremes by emphasizing historical calculation rather than current rate or extremes.

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 'what the carry has actually been' gives a clear use case: historical funding performance for a USDT perpetual. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough that an agent can infer when this tool is 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?

With no annotations and no output schema, the description carries the behavioral burden well: it discloses the $0.002 USDC cost, the x402 payment mechanism, Solana mainnet, and the Hyperliquid data source. It also enumerates the returned fields, though it does not describe response shape or rate limits.

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

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

Two terse, information-dense sentences: the first delivers the data scope and venue, the second adds the cost and payment rail. No filler or redundant wording.

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

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

For a zero-parameter paid data tool, this is largely complete: an agent knows the assets, the market data returned, the venue, the cost, and the payment network. A response format example would be a nice addition, but it is not a blocking gap given the simplicity of the call.

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 is empty, so there are no parameter semantics to explain. The baseline 4 applies because the tool requires no arguments and the description provides all necessary 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?

The description clearly states the resource: current SOL and BTC perp funding rates, mark prices, and open interest on Hyperliquid. This is specific enough to distinguish it from many sibling tools by asset and data type, though it does not explicitly name an alternative.

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 word 'Current' and the explicit SOL/BTC/Hyperliquid scope imply when this tool is appropriate. However, there is no explicit when-not-to-use guidance or comparison to sibling tools like get_funding_history, get_funding_cross, or get_open_interest.

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

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

With no annotations, the description carries the behavioral burden. It usefully discloses the $0.005 USDC cost per call, the x402 payment method, and Solana mainnet context. However, it does not describe response format, rate limits, data freshness, or any failure behavior, so transparency is only partial.

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 with the core subject front-loaded and the cost caveat appended. Every clause adds distinct value, with no filler or redundancy.

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

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

For a zero-parameter tool with no output schema, the description provides enough context to understand the meaning of the data (Jito bundle tip percentiles, SOL) and a cost warning. The main gap is that 'landing recommendation' is not explained further, but this is a minor omission for such a simple 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 tool has zero parameters, so there is no input schema detail to supplement. The description adds relevant context about what the returned data represents, which is the maximum possible value for a no-argument tool.

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

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

The description identifies a specific resource (Jito bundle tips), the specific metrics (p25-p99 percentiles in SOL), and an additional output (landing recommendation). This clearly differentiates it from sibling tools like get_priority_fees or get_sol_price, even without naming them.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The practical scenario is implied by the data described, and the cost warning suggests deliberate use, but the description does not tell an agent how to choose between this and related fee/fee-estimate 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?

With no annotations, the description carries the burden of behavioral disclosure. It reveals the 15-minute delay, the limited asset universe, and the 'taster' nature of the free offering. It does not detail output format or empty-result behavior, but for a zero-parameter read-only lookup the essential behavioral traits are disclosed.

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

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

The description is compact and front-loaded with the key selling point and scope. The main redundancy is the word 'FREE' appearing at the start and 'Free.' at the end, which costs a little efficiency but does not obscure meaning.

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

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

For a zero-parameter, no-output-schema tool, the description covers the essential operational context: asset coverage, delay, free tier, and the real-time alternative. It is slightly ambiguous whether the response is one liquidation per asset or a single aggregate, but the simplicity of the tool keeps this from being a major gap.

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

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

There are zero parameters, and the schema has no properties, so there is nothing to document. Per the baseline for zero-parameter tools, the description is not expected to add parameter-level semantics, and it does not need to.

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

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

The description states a specific verb and resource: it returns the last liquidation for a named set of assets (SOL, BTC, ETH, XRP, DOGE), and immediately distinguishes itself from the real-time sibling get_recent_liquidations. The scope and limitation (15-min delayed, free taster) make the tool's 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 explicitly tells the agent when to use this tool versus the alternative: use get_last_liquidation for the free delayed snapshot, and get_recent_liquidations for real-time data. This direct routing to a named sibling is exactly the guidance agents need.

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

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

With no annotations, the description carries the behavioral burden. It discloses the data source, the nature of the data, what the output contains, and the price/cost. It does not mention rate limits, auth, or exact response shape, but it goes well beyond minimum expectations for a read-only data tool.

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

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

The description is compact and front-loaded with the core purpose, followed by a key data-quality differentiator and the pricing. No filler or repeated schema content; each sentence carries useful information.

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

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

For a 3-parameter, no-output-schema tool with numerous sibling liquidation tools, the description is quite complete: it explains the resource, the output fields, the data source, and the cost. It lacks an explicit return-structure example, but the listed output elements give enough context for correct invocation.

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

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

Schema coverage is 100%, so the schema already documents all three parameters. The description adds little parameter-specific meaning beyond 'last N hours' aligning with hours and 'per price zone' aligning with buckets. This meets the baseline for high schema coverage.

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

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

The description states exactly what the tool does: provides a liquidation heatmap by price level from the tool's own tape, with USD, prints, long/short split, and hottest zone. It clearly distinguishes itself from entry-price estimate tools and from sibling liquidation-history/stats tools.

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

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

The description gives clear context for when to use this tool: when you need actual liquidation prints aggregated by price level over the last N hours. It does not explicitly name alternatives or state when not to use it, but the 'real prints, not entry-price estimates' phrasing signals the appropriate 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by disclosing the data granularity, fields returned, coverage scope, lookback limit, and the $0.05 USDC per-call cost via x402 on Solana mainnet. It does not mention rate limits, pagination, or response format, but for a read-only data retrieval tool the important operational traits are surfaced.

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

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

The description is compact and front-loaded with the essential definition of what the tool returns before moving to scope and cost. The uniqueness claim ('this data exists nowhere else') and Bybit context add credibility but are not strictly necessary for invocation. Overall, it is efficient with only minor non-essential content.

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

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

Given there is no output schema, the description appropriately summarizes the response contents: total/long/short USD, prints, and biggest print per bucket. It also covers time range, universe selection, and cost, which are the key contextual facts an agent needs. A fully complete description might detail the exact response structure or error behavior, but what is provided is sufficient for most invocation scenarios.

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

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

The schema already covers all 4 parameters with descriptions, so the baseline is 3. The description adds useful semantic context: 'time-bucketed' informs bucket_min, 'up to 7 days back' maps to hours, and 'any USDT perp or the whole universe' clarifies scope and symbol. This goes beyond the schema by explaining why and how the parameters combine to shape the returned data.

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

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

The description clearly identifies the resource: historical liquidation tape, time-bucketed with total/long/short USD, prints, and biggest print per bucket. It is specific about scope (any USDT perp or whole ~600-perp universe) and lookback (up to 7 days), making the tool's function clear. However, it does not explicitly name sibling tools like get_recent_liquidations or get_last_liquidation to differentiate them, so it falls short of the strongest sibling-distinguishing bar.

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 historical liquidation analysis by emphasizing 'HISTORICAL' and time-bucketing, and it clarifies acceptable inputs (any perp or universe, up to 7 days). It does not provide explicit when-to-use or when-not-to-use guidance versus siblings, nor does it mention alternatives. The usage context is clear enough to infer the intended case but lacks direct routing.

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

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

With no annotations, the description carries the behavioral burden, and it does a solid job: it describes the aggregation logic, venue coverage, per-symbol output fields, and importantly the $0.02 USDC per-call cost on x402/Solana mainnet. It does not explicitly state read-only behavior, but this is a get operation with no mutation language and no destructive hints.

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

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

Four sentences, each adding value: what is returned, per-symbol breakdown, positioning for urgency, and cost/payment method. There is no filler, and the most important information is front-loaded.

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

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

For a simple tool with 2 optional fully-documented parameters and no output schema, the description is complete: it explains return fields, data universe, venue coverage, and monetization. An agent can select and invoke this tool correctly without needing further 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 description coverage is 100%, and both limit and window_min already have clear descriptions with ranges and defaults. The tool description adds little beyond 'top symbols' and 'RIGHT NOW', so it does not need to compensate; baseline 3 is appropriate.

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

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

The description names a specific verb+resource: top symbols ranked by liquidation USD across ~600 USDT perps on Bybit, OKX, and Binance. It enumerates per-symbol fields (total liquidated, long/short split, biggest print, venue count, dominant side), which clearly distinguishes it from sibling liquidation tools like get_last_liquidation or get_liquidation_stats.

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 phrasing 'What is blowing up RIGHT NOW' and 'fastest read on where leverage is being flushed' implies usage for urgent liquidation monitoring, but there is no explicit when-to-use, when-not-to-use, or comparison with alternatives. Among many liquidation-related siblings, the agent has to infer which one to pick.

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

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

With no annotations, the description carries the full burden. It transparently discloses the pay-per-call cost, the payment rail (x402), and the network (Solana mainnet), which are critical behavioral traits for an agent deciding whether to invoke it. It does not mention return format or error behavior, but for a read-only stats endpoint the cost and scope are the most important disclosures.

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 packed sentences with no filler. The first sentence front-loads the resource and all relevant data components, and the second adds the cost detail. Every sentence contributes useful information.

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

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

For a zero-parameter tool with no output schema, the description is quite complete: it states the instruments, time windows, metric types, and cost. It does not specify the exact JSON return shape, but that is not essential for an agent to invoke the tool correctly.

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

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

The tool has zero parameters and the input schema is an empty object with 100% coverage, so there are no parameter semantics to explain. The baseline of 4 applies because the description correctly focuses on the output content and cost rather than parameters.

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

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

The description clearly identifies the resource: liquidation aggregates for a specific set of 5 majors, with concrete data elements (1h/24h totals, longs vs shorts USD split, biggest print, per-exchange breakdown). This distinguishes it from sibling liquidation tools by scope, though it lacks an explicit verb like 'retrieve' and does not name a sibling.

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 use case by specifying exactly what data is returned, so an agent can infer when this tool fits. However, it provides no explicit guidance on when to use this tool versus the many liquidation-related siblings such as get_recent_liquidations or get_liq_history, and no exclusion 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?

With no annotations, the description carries the burden and does add useful behavioral context: the $0.01 USDC cost per call and the x402/Solana mainnet execution environment. Yet it does not describe the response format or rate limits, leaving some behavioral gaps.

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

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

Two sentences, front-loaded with the core metric and a compact cost/network note. Every sentence earns its place with no redundancy or filler.

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

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

For a simple one-parameter read tool, this is reasonably complete: it defines the metric, scope, trends, cost, and network. However, with no output schema, it omits the return value shape and the payment mechanics, leaving minor operational ambiguity.

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

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

The schema already covers the single parameter 100% with a type and example. The description reinforces that the tool works for ANY USDT perp but adds little semantic detail 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 states the specific metric (long/short account ratio), the scope (ANY USDT perp), and the temporal dimensions (1h and 24h trend). The 'retail crowding gauge' label adds interpretive clarity and differentiates this tool from sibling data fetchers.

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 'retail crowding gauge' tag implies a use case, and the scope qualifier 'ANY USDT perp' suggests when it applies. However, it names no alternative tools and gives no explicit when-to-use/when-not-to-use guidance, so usage is only implied.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It does disclose an important operational trait: the exact $0.003 USDC fee and the x402/Solana mainnet payment path. It does not mention data freshness, return format, or whether wallet authorization is required, so coverage is partial.

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: the first front-loads the returned data, and the second gives the pricing. There is no filler, repetition, or 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?

For a no-parameter read-only snapshot, the description covers what data the agent will receive and what the call costs. It does not specify exact output fields or freshness, but the low complexity and empty schema make those minor gaps.

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

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

The tool has zero parameters, so there is no ambiguity for the agent to resolve. No parameter documentation is necessary, and the baseline of 4 is appropriate.

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

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

The description states exactly what the tool returns—SOL and BTC prices, funding rates, and Fear & Greed—under the clear verb 'get market snapshot.' The phrase 'in one call' also distinguishes it from the many single-metric sibling tools such as get_btc_price and get_fear_greed.

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 aggregation wording implies this tool is for a combined market overview, and the fee hints at a cost tradeoff. However, it never explicitly says when to prefer this over calling individual siblings or when to avoid it, such as when only one metric is needed or when free endpoints would suffice.

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

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

With no annotations, the description carries the safety/cost/burden disclosure. It explicitly states the $0.02 USDC cost per call and the x402/Solana mainnet execution context, and describes the baseline logic (30min+ baseline) and output context. It stops short of disclosing exact thresholds or response shape, but this is sufficient for a simple read-only scan.

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 short sentences front-load the core behavior first, then the use-case label, then cost. Every clause adds distinct value with zero filler.

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

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

The tool has one optional parameter, no output schema, and no annotations, so the description must carry the burden. It covers the universe, the detection logic, the funding/price context, and the cost. It does not explicitly describe the return format or ranking order, but for a screener of this simplicity the description is nearly complete.

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

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

The input schema already describes `limit` as 'top N, 1-25, default 10' with 100% coverage, so the baseline is 3. The description does not add anything specific to the parameter beyond naming the scan universe, so it neither helps nor hurts.

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

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

The description identifies a specific screening behavior ('Abnormal open-interest jumps across ~600 USDT perps vs a 30min+ baseline'), names the output context (funding and price), and labels the tool as a 'Squeeze/flush precursor screener'. This clearly distinguishes it from siblings like get_open_interest or get_squeeze_score.

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

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

It states the intended use case ('Squeeze/flush precursor screener') and the scan universe, providing clear context for when to call it. It does not explicitly name alternative tools or exclusion conditions, but the context is strong enough for an agent to route correctly.

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

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

With no annotations, the description carries the full behavioral burden and does well by disclosing the per-call cost, the x402 payment mechanism, and the Solana mainnet requirement. It also specifies the data sources and change periods, though it could mention error behavior or whether data is live/cached.

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

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

The description is two sentences, front-loaded with the core functionality and data returned, then adds the sibling distinction and cost. There is no filler; every clause contributes selection-relevant information.

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

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

For a one-parameter tool with no output schema, the description gives a solid list of what is returned (Bybit base/USD values, change windows, OKX OI) and the payment requirement. It does not spell out the exact response JSON structure or error cases, but the included details are enough for an agent to call it and interpret the result

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

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

The schema covers the symbol parameter well with a description and example (SOLUSDT). The description adds the word 'ANY' to emphasize broad acceptance but provides no additional format, case, or constraint details beyond the schema, so it meets but does not exceed 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 open interest for any USDT perpetual, with specific data points (Bybit OI in base and USD, 1h/24h change, plus OKX OI). It also distinguishes itself from a sibling by noting get_positioning covers only SOL and BTC, making selection 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?

It explicitly states the tool's coverage ('ANY USDT perp') and contrasts it with an alternative ('get_positioning covers SOL+BTC only'), which directly guides an agent on when to choose this tool. The cost note also provides practical usage context for when paid calls are acceptable.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It explicitly discloses the $0.01 USDC cost, the x402/Solana mainnet execution path, the read-only nature of the call, and the output fields. It does not mention rate limits or error behavior, but the most important behavioral traits are covered.

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 deliver the metric, scope, output fields, cost, and execution network with no filler. The core concept is front-loaded, making it easy for an agent to scan and act on.

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 two-parameter read with no output schema, the description provides the essential invocation context: input universe, window semantics, output fields, and cost/network. It stops short of specifying exact return shape or sign conventions, but nothing critical for deciding whether to call the tool is missing.

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

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

Schema description coverage is 100%, so both bps and symbol are already documented with types, ranges, defaults, and examples. The description reinforces that the symbol must be a USDT perp and that bps is the window size, but it adds no meaningful parameter information 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 states the exact metric (bid/ask resting-liquidity imbalance within ±N bps of mid), the applicable universe (any USDT perp), and the returned outputs (USD each side, ratio, skew). This clearly differentiates it from sibling tools like get_orderbook_walls, which focus on walls rather than imbalance.

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 the tool—when an orderbook imbalance within a bps window is needed for a USDT perpetual—but it does not explicitly compare to alternatives or state when not to use it. The cost warning is useful operational context but does not serve as a routing guideline.

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

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

With no annotations, the description carries full burden. It transparently discloses that the call costs $0.01 USDC via x402 on Solana mainnet, which is important behavioral and economic context. It also describes what data the tool returns, including largest resting orders, USD size, and distance from mid. It does not discuss edge cases such as empty books, but the key operational trait (paid call) is disclosed.

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 redundancy: the first states the purpose and output, the second gives the cost and payment rail. The key differentiator, cost, is placed early in the second sentence. 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 simple two-parameter tool with no output schema, the description is largely complete: it explains the output content, scope, and a critical paid-call caveat. Missing guidance about choosing it over sibling orderbook tools is the main gap, but the low complexity keeps the absence from being fatal.

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 both `symbol` and `top` are already documented in the schema. The description reinforces the symbol type by saying 'any USDT perp' but adds no new parameter-specific meaning beyond that. This earns the 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?

The description uses a specific verb and resource: it identifies orderbook walls as the largest resting orders on each side of the book for USDT perps, and specifies the output includes USD size and distance from mid. It is clear about scope, though it does not explicitly differentiate itself from the closely related sibling get_orderbook_imbalance.

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

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

No guidance is given on when to use this tool versus alternatives like get_orderbook_imbalance or other orderbook-related tools. The only usage hint is the generic 'for any USDT perp' scope, which describes applicability but not 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?

With no annotations, the description carries the burden of behavioral disclosure. It adds meaningful operational context: 5-minute sampling cadence, proprietary data source, and a $0.02 USDC cost per call via x402 on Solana mainnet. These details go beyond the schema and help the agent anticipate freshness, cost, and uniqueness, even though error behavior and auth requirements are not mentioned.

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

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

The description is compact and front-loaded with the core metric definition, followed by data provenance and cost. Every sentence contributes distinct information—what, how sampled, and cost. The first sentence is somewhat long and comma-heavy, but it avoids fluff and remains readable.

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

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

Given there is no output schema and no annotations, the description does a solid job of telling the agent what to expect: the metric, the units, the aggregation split, and the cost. It could have specified the exact response shape or the effect of the hours parameter, but the schema covers hours and the description gives enough to invoke correctly. The paid-call warning is an important contextual detail that is well handled.

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 both parameters (symbol and hours) are already documented with examples and valid ranges. The description adds little parameter-specific meaning, though '24h stats' corroborates the default lookback. Baseline of 3 applies because the schema handles the param semantics and the 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?

The description clearly defines what the tool returns: peg deviation in bps for a tokenized US equity, comparing on-chain DEX price to underlying last real trade, with 24h stats split by market hours. It distinguishes the tool from generic price tools by highlighting the unique collector data ('this tape exists nowhere else'). The only minor gap is the lack of an explicit verb like 'Returns' or 'Lists', though the tool name and context make the action obvious.

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

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

The description gives no explicit guidance about when to use this tool versus related siblings such as get_peg_universe or get_peg_sessions. It implies relevance to tokenized equities and peg analysis, but does not state exclusions, prerequisites, or conditions that would route an agent here over an alternative. This leaves usage decisions mostly to inference.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It adds meaningful operational context: computed metrics per session, the control baseline, the worst-window flag, and the $0.03 USDC cost via x402 on Solana mainnet. It does not cover response format or error behavior, but the core behavioral traits are disclosed.

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 filler: the first packs analytical scope and output metrics, the second adds the control baseline and cost. It is front-loaded and every clause 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 and no annotations, the description adequately explains what the tool returns: per-session mean, p95, max bps, median liquidity, and a flagged worst window. A response format example would make it fully complete, but the essentials for selecting and invoking the tool are present.

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

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

The input schema already documents both parameters with 100% coverage, so the baseline applies. The description adds no parameter-specific meaning beyond what the schema provides for symbol and days.

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

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

The description clearly states the tool's exact function: peg deviation broken out by trading session, with specific metrics and a flagged worst off-hours window. This distinguishes it from sibling peg-related tools through the explicit session dimension and statistical detail.

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 should be used when session-level peg deviation analysis is needed, especially with market-open as a control. However, it never explicitly states when to prefer this over alternatives like get_peg_deviation, nor does it say 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?

With no annotations, the description carries the transparency burden. It clearly discloses that dead pools are excluded to avoid misleading perfect-peg readings, that the call costs $0.05 USDC on x402/Solana, and that results are ranked with specific deviation and liquidity fields. This is unusually candid about data handling and 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?

Three sentences deliver the core behavior, ranking criteria, exclusions, and pricing without fluff or restating the tool name. The most important ranking information is front-loaded, and each sentence adds distinct information.

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

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

The description covers the returned ranking fields, ordering, exclusion behavior, cost, and network, which is substantial for a tool with zero required parameters and no output schema. It does not specify pagination or exact response envelope, but the essential calling context is complete enough for an agent to invoke and interpret it.

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

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

Both parameters are already fully described in the schema (lookback range/default and liquidity filter), so the description adds little parameter-level guidance. The schema coverage is 100%, so the baseline of 3 applies; the description doesn't need to compensate.

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

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

The description specifies a concrete resource: every tokenized US equity tracked, with a clear ranking criterion (off-hours peg risk) and key output fields. This distinguishes it from single-asset or session-level peg tools in the sibling list, even though no sibling is named.

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 'Every tokenized US equity we track' makes the broad survey use case clear: call this to get the full ranked universe rather than one asset's peg behavior. It does not explicitly state when not to use it or name alternatives, so the guidance is contextual rather than exclusionary.

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

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

No annotations are provided, so the description carries the full burden. It adds genuinely useful behavior beyond the schema: a hard cost of $0.004 USDC per call via x402 on Solana mainnet, plus the data composition and venue (Bybit, 1h/24h deltas). It does not cover output format, data freshness, rate limits, or failure modes, so it is solid but not complete.

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

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

Two sentences, each earning its place: the first packs metric composition, venue, timeframes, and interpretation; the second packs cost and payment rail. There is no filler and no repetition of the tool name.

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

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

For a zero-parameter read-only data call with no output schema, the description covers the key decision inputs — what metrics come back, from where, and at what cost. The main lacuna is the return shape (single combined reading vs. separate SOL/BTC values), but invocation itself is fully specified.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify about arguments; the baseline of 4 applies. The description instead usefully explains what the returned data measures (long/short ratio, OI change), which is the relevant semantic content for this parameterless call.

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 exactly what the tool returns: SOL+BTC positioning composed of long/short account ratio (labeled as retail crowding) plus open interest with 1h/24h change on Bybit. This distinguishes it from overlapping siblings like get_long_short and get_open_interest by naming the venue and the combined metric composition. Minor deduction: it is phrased as a noun phrase rather than a declarative verb+resource statement.

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

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

The 'retail crowding' gloss implies a use case — assessing how crowded retail positioning is — and the venue/timeframe scoping gives selection context. However, there is no explicit when-to-use or when-not-to guidance, and with 52 siblings including get_long_short and get_open_interest, explicit routing instructions would materially help an agent choose this tool over the 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?

With no annotations provided, the description carries the behavioral transparency burden. It usefully discloses the real-time nature of the estimate, the unit and range of returned values, and the $0.005 USDC cost per call via x402 on Solana mainnet, which is important beyond the tool name alone.

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

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

The description is compact and front-loaded: it states what the tool returns, in what units, and for whom, then adds cost. Every sentence adds meaningful information with no filler.

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

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

Given that there are no parameters and no output schema, the description adequately covers the key return values, units, use case, and cost. It could be slightly stronger by naming related sibling tools or describing the exact response shape, but it is sufficiently complete for a low-complexity 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 tool has zero parameters, so parameter semantics are not a concern. The baseline of 4 applies because there are no inputs for the description to clarify.

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 a Solana priority-fee estimate with all levels from min to unsafeMax, specified in micro-lamports/CU, plus a recommended tip. It is specific about the resource and output contents, though it does not explicitly distinguish itself from sibling tools like get_jito_tips.

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 'For bots that need txs to land' provides clear usage context for when this tool is appropriate. It does not mention alternatives or when not to use it, but the intended scenario is concrete enough for an agent to select 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose the $0.003 USDC per-call cost and Solana x402 execution, plus the unthrottled nature of the data. It does not mention rate limits, auth, or failure behavior, but the key operational context for a paid read-only tool is covered.

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 compact sentences front-load the primary deliverable, then coverage, then cost. There is no filler, no repetition of schema details, and every sentence adds distinct 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 four optional parameters, full schema coverage, and no output schema, the description covers the returned fields, venue scope, symbol breadth, and cost. It stops short of specifying ordering or exact output shape, but an agent has enough information to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so the schema already documents all four parameters. The description adds some useful context by noting the tape is complete and covers ~600 USDT perps, which enriches the meaning of symbol and scope, but it does not substantially expand on parameter formats or defaults.

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

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

The description opens with a specific verb and resource: 'Recent perp liquidations across Bybit, OKX and Binance.' It enumerates the returned fields and clarifies broad symbol coverage (~600 USDT perps), which distinguishes it from sibling liquidation tools that target single assets, history, or stats.

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 'recent' and 'complete unthrottled tape' give clear context that this is for current full liquidation flow rather than historical or aggregated liquidation views. However, it does not explicitly name alternatives like get_liq_history or get_last_liquidation or state when not to use them.

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

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

No annotations are provided, so the description carries the full burden. It discloses the key behavioral fact of a $0.005 USDC cost per call and the payment mechanism (x402 on Solana mainnet), which is important for an agent deciding whether to invoke the tool. It also enumerates the returned data. It does not discuss side effects, but the 'get' name and network-health framing imply a read-only operation.

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

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

The description is a single compact sentence that front-loads the purpose, then lists concrete output examples, then adds the cost caveat. Every part earns its place with no repetition or filler.

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

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

For a zero-parameter tool without an output schema, the description is complete: it states what the tool provides, includes representative return fields, and flags the cost. An agent has everything needed to select and invoke it correctly.

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

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

The tool has zero parameters, so the schema fully describes the input. The description adds value by clarifying the output fields, which is the relevant semantic content for this parameterless tool.

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

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

The description clearly states the resource (Solana network health) and the specific metrics returned (average TPS, current slot, epoch, epoch progress). This distinguishes it from siblings like get_sol_price or get_basis, which target different data domains.

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 makes the use case clear: retrieving Solana network health metrics. It does not explicitly mention alternatives or when not to use it, but the metric list and 'network health' framing provide sufficient context for tool selection.

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

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

With no annotations provided, the description carries the full burden and does so well. It discloses multi-source fallback behavior, the null semantics of confidence and publish_time fields, and the $0.001 USDC cost per call. These are meaningful behavioral details beyond a generic price lookup.

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 compact sentences with no filler. It front-loads the core purpose, then packs high-value behavioral and cost information into the second sentence. 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?

For a zero-parameter, no-output-schema tool, the description is complete: it states the asset pair, the data sources, the fallback behavior, the nullable fields, and the cost. An agent has enough information to select and invoke the tool correctly without further research.

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

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

The tool has zero parameters and 100% schema coverage, so the baseline for this dimension is 4. The description adds source/fallback context that indirectly informs the meaning of the returned data, though no parameter-specific explanation is needed.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Live SOL/USD spot price.' It also adds useful detail about multi-source aggregation, which distinguishes it from sibling tools like get_btc_price and makes its scope unambiguous.

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

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

The description gives clear context: this tool is for current SOL/USD spot price needs, including source behavior and cost. It does not explicitly name alternatives or exclusion criteria, but the concise scope plus sibling list makes the intended use obvious.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It usefully discloses that the call costs $0.02 USDC and that the edge is pre-fee, which are important behavioral details. However, it does not describe what happens when no arbitrage exists, whether the call can fail, or any rate or data freshness considerations.

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

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

The description is two sentences and every clause earns its place: it names the resource, the venues, the computed metric, the pre-fee caveat, and the cost. It is front-loaded with the core purpose and keeps supplementary billing information at the end.

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 read-only query tool, the description is mostly sufficient: it states venue scope, the metric, and the cost. However, there is no output schema and no description of return shape or edge-case behavior, so an agent must infer what the tool actually returns in a no-opportunity scenario.

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

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

The schema already describes the only parameter, 'symbol', as a USDT perp symbol with the example SOLUSDT, so schema coverage is complete. The description adds 'USDT perp' context but does not materially extend the parameter meaning beyond the schema. A 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 clearly identifies what the tool provides: best bid/ask for a USDT perp across Bybit, OKX, and Hyperliquid, plus the best cross-venue edge in bps. It is specific about venues and the metric, and the phrase 'cross-venue edge' helps distinguish it from simpler quote tools. It lacks an explicit verb like 'returns' or 'gets,' but the intent is still unambiguous.

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

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

The description gives no guidance on when to prefer this tool over siblings or when not to use it. It implies usage for checking cross-venue spread/arb opportunities, but it does not mention alternatives or exclusion criteria. The cost warning is useful, but it is not a usage guideline.

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

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

With no annotations, the description carries the behavioral disclosure burden. It transparently discloses the paid nature of the call ($0.1 USDC via x402 on Solana mainnet), the scoring range, and the composite factors. It does not mention auth, failure modes, or rate limits, but the cost and payment rail disclosure is substantial and beyond what the schema offers.

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

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

The description is compact and front-loaded: it states what the tool provides, the score range, the components, the use case, and the cost in three sentences. Every sentence earns its place and there is no redundant filler.

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

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

For a single-parameter tool with no output schema, the description explains the output concept (a 0-100 score), the domain (USDT perps), the inputs it composites, and the cost. It does not specify the exact response structure, but 'one number' plus 'score 0-100' gives an agent enough to understand the return value.

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

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

Schema coverage is 100% and the schema already explains that symbol is a USDT perp symbol like SOLUSDT. The description adds context like 'any USDT perp' but does not materially expand the parameter semantics, so the baseline of 3 is appropriate.

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

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

The description clearly states a specific output (short-squeeze / long-flush score 0-100 for USDT perps) and explains what the score is composed of. It does not explicitly name or contrast itself with sibling tools like get_long_short or get_positioning, so it stops short of full sibling differentiation.

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

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

The description gives a concrete use case: answering whether a trade is crowded and about to hurt someone, and it scopes the tool to any USDT perp. It does not explicitly state when not to use it or point to alternatives, but the usage context is clear enough for an agent to select it purposefully.

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

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

With no annotations provided, the description carries the full behavioral burden and it does add meaningful operational context: the call costs $0.01 USDC and executes via x402 on Solana mainnet. It does not mention rate limits or auth details, but the payment rail requirement is a valuable disclosure beyond the tool name and schema.

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

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

The description is two compact clauses and every part earns its place: the data content, the analytical framing, and the critical cost/payment constraint. It is front-loaded with the main result and does not waste tokens.

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

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

For a zero-parameter tool with no output schema, the description provides enough information to understand what will be returned and why it matters. It could have added more about exact units or formatting, but the essential context is present.

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

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

The tool has zero parameters, so the schema contains no parameter semantics to document. The description correctly focuses on the output concept instead of parameter details, matching the baseline for a parameterless tool.

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

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

The description clearly identifies the resource (stablecoin supply) and the specific computed metrics (7d/30d deltas, top stables), using an explicit verb. It also distinguishes itself from the many sibling market-data tools by framing this as the macro risk-on/risk-off dial.

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

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

It gives a clear use case: use this when you need the macro risk-on/risk-off stance via stablecoin supply dynamics. It does not explicitly name alternatives or exclusion conditions, but for a zero-parameter data snapshot the intended context is sufficiently clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reasonably discloses the paid nature of the call, the exact cost, the payment rail (x402), and the network (Solana mainnet). It does not mention data freshness, whether the result is cached, or failure behavior, but for a simple read-only token data look-up the disclosed cost and network context are strong additions.

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

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

The description is two sentences with no filler. The first sentence states the tool's action and outputs, the second provides the key differentiation from a sibling and the cost implication. All information earns its place and is front-loaded.

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

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

The description covers the tool's purpose, output highlights, relation to get_token_risk, and cost, which is substantial given only one parameter and no output schema. The main gap is that it does not specify exactly how many accounts are returned or whether there is pagination/limiting. This is minor for a holder-lookup tool, so the definition is nearly 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% and the single parameter 'mint' is already fully documented as an SPL token mint address in base58. The description adds only the broad 'any SPL token' claim and the output focus, which does not materially deepen the semantic understanding of the parameter. This matches the baseline for fully schema-documented parameters.

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

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

The description clearly identifies the resource (SPL tokens) and the specific action (get top holders), and specifies the output dimensions: per-account share and top1/top5/top10 concentration. It also differentiates itself from the sibling get_token_risk by positioning this as the deeper holder-level cut. This gives an agent a precise, non-ambiguous purpose.

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

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

The phrase 'Deeper cut than get_token_risk's summary' provides a direct comparison to a sibling tool and implies when this tool is preferable: when holder-level detail beyond a summary is needed. It does not explicitly state when not to use it or list exclusions, but the context is clear enough for correct selection among the many get_* siblings.

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

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

With no annotations provided, the description carries the full burden and does well by disclosing the $0.005 USDC per-call cost, the x402 payment rail, the Solana mainnet requirement, and the Helius DAS data source. It does not cover auth or rate limits, but the cost disclosure is a meaningful behavioral trait beyond a simple read operation.

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

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

The description is a single front-loaded sentence that packs in the resource, return fields, data source, network, and pricing with zero filler. Every clause contributes useful information.

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

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

For a one-parameter read-only tool, this description is complete: the schema covers the input, and the description names the output fields, data source, network, and per-call cost. The absence of an output schema is offset by the explicit field list.

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 covers the single mint parameter at 100%, so the schema already documents that it expects an SPL token mint address in base58. The description adds no parameter-level detail beyond the schema, making the baseline 3 appropriate.

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

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

The description clearly identifies the resource as SPL token metadata and enumerates the exact fields returned (name, symbol, decimals, supply, price). It is easily distinguished from sibling tools like get_token_holders or get_token_risk because it focuses specifically on token metadata.

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

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

The description does not explicitly name alternatives or exclusion conditions, but it gives clear context: this tool is for retrieving SPL token metadata and pricing. For a focused metadata lookup, that is sufficient guidance; no ambiguity exists about when it applies.

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

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

There are no annotations, so the description carries the full behavioral disclosure burden. It does well by revealing a real cost per call, the x402 payment mechanism, the network, and a specific limitation. It does not mention caching, latency, or exact output shape, but the most operationally relevant behavior is disclosed.

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

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

The description is compact: two sentences that front-load the tool's purpose and output categories, then provide scope limitations and cost/network details. There is no filler or redundant restatement of the tool name.

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

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

For a one-parameter tool with no output schema, the description covers the main selection and invocation needs: what the tool measures, what it does not measure, the required input, the network, and the cost. It could be slightly more specific about the exact risk flags or return format, but nothing essential is missing.

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

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

The input schema already fully documents the single 'mint' parameter as an SPL token mint address in base58, so the description adds no additional parameter-level detail. With 100% schema description coverage, the 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 that the tool returns SPL token rug-risk signals and specifies the signal categories: mint/freeze authority status, top holder concentration, and risk flags. It differentiates itself by explicitly saying it is not a honeypot/LP-lock checker, though it does not name a specific sibling alternative.

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

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

The description implies the tool is for assessing token rug risk and provides an explicit scope exclusion: it is not a honeypot/LP-lock checker. It also surfaces the $0.01 USDC cost and Solana mainnet context, which helps the agent decide whether to invoke it. However, it does not name an alternative tool or state a concrete 'use this when...' condition.

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

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

With no annotations provided, the description carries the disclosure burden and does disclose meaningful non-schema traits: a $0.01 USDC cost per call via x402 on Solana mainnet, funding data being attached, and the ~600-perp universe. It does not explicitly state that the call is read-only, but the tool name and screener framing make that a minor omission.

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 tightly written sentences with no redundant phrasing. Core scope is front-loaded, and the cost/network detail is appended cleanly as supplementary operational 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?

Given there is no output schema and no annotations, the description covers the essential context: universe, time window, data included, cost, and network. It does not describe exact return shape or ordering, but for a simple two-parameter screener the definition 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%, so the schema already fully documents limit and min_turnover_usd, including defaults and bounds. The description adds only contextual gloss such as "liquidity floor" and "funding attached," which is helpful but not necessary for parameter understanding.

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 screens 24h top gainers and losers across ~600 USDT perps, naming both a specific resource and the screening action. It also calls itself the "what moved" screener, which distinguishes it from the many other market-data sibling tools.

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

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

The phrase "what moved" screener implies this tool is for reviewing significant 24h perp price moves, but it does not explicitly say when to choose it over alternatives. It names no sibling tools, exclusion criteria, or complementary tools, leaving routing partially to inference.

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

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

No annotations are provided, so the description carries the full burden. It discloses a concrete behavioral trait—cost of $0.01 USDC per call via x402 on Solana mainnet—and enumerates the metrics returned. It does not specify exact response structure or units, but for a parameterless read-style tool, the covered behaviors are meaningful and clear.

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 aggregate purpose and metric list are front-loaded, and the cost/network note is appended efficiently. 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?

For a parameterless aggregate tool with no output schema, the description covers what the agent gets, what it costs, and where it runs. It lacks exact field names and units, but the listed metric categories provide enough context to justify invocation and anticipate the response shape.

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 is empty with zero parameters, so there is no parameter meaning for the description to add. The baseline for a zero-parameter tool is 4, and the description appropriately focuses on the return contents instead of arguments.

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 a composite resource: a single-call snapshot of SOL+BTC prices, funding, Fear & Greed, long/short positioning, open interest, and liquidation stats. This distinguishes it from the many single-metric sibling tools like get_sol_price, get_funding_rate, and get_liquidation_stats.

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 frames this as the 'complete pre-trade picture' and 'full market state in one call,' which clearly signals when an agent should use it: when it needs a broad multi-metric view before trading. It does not explicitly name alternatives like get_btc_price or get_open_interest for single-metric needs, but the aggregate framing strongly implies that distinction.

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

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

With no annotations, the description carries the burden and does disclose important operational traits: DeFiLlama-backed data, $0.005 USDC cost per call, x402 on Solana mainnet, and 1d/7d change fields. It does not describe the exact response shape, but the purpose statement implies the returned content well.

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

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

The description is compact and front-loaded: the core purpose appears first, followed by the data source and cost. Every sentence earns its place with 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?

For a simple tool with one optional parameter and no output schema, the description covers purpose, alternatives mode, example behavior, and the cost/payment rail. The main gap is lack of a concrete response shape, but the tool is simple enough that this is a minor omission.

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 target parameter is already described with examples and the omit-for-top-chains behavior. The description adds little beyond the schema, but for a single optional parameter the schema fully carries the 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 states what the tool does: fetch TVL for a DeFi protocol or top-15 chains ranking, backed by DefiLlama. It names a specific resource and behavior, and there is no obvious sibling tool with the same purpose.

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

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

The description gives clear usage context: provide a protocol slug/name or omit for top chains. It does not explicitly name alternatives or exclusions, but the sibling list contains no direct TVL duplicate, so the guidance is 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It does usefully disclose a $0.02 USDC cost, x402 payment rail, and Solana mainnet execution, which is valuable beyond the name and schema. However, it does not describe return format, latency, failure modes, or whether results are point-in-time or aggregated.

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 tight sentences with no filler. The purpose is front-loaded in a catchy but concrete phrase, followed by the output dimensions and the essential cost/payment detail. 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?

For a simple two-parameter tool with no output schema and no annotations, the description covers purpose, scope, output dimensions, and cost. The main gaps are the lack of alternative-tool routing and no indication of the response shape, but these are minor for a read-only lookup with well-documented 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 the schema already documents the hours range/default and symbol examples. The description adds 'any symbol or whole universe,' which reinforces the optional symbol semantics, but it does not explain the hours parameter beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description names a specific verb and resource: per-exchange liquidation share across Bybit/OKX/Binance, with long/short split and biggest print, and scope of any symbol or whole universe. This clearly distinguishes it from overlapping liquidation siblings like get_liquidation_stats or get_recent_liquidations.

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

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

There is no explicit guidance on when to use this tool versus alternatives, and no exclusions or routing hints relative to sibling tools like get_liquidation_leaders or get_liq_heatmap. The intended context is only implied by the phrase 'Which venue is flushing whom' and the per-exchange focus.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It reveals the paid nature of the call ($0.01 USDC), the x402/Solana mainnet payment rail, and the calculation basis (daily closes, annualized) — meaningful context beyond the schema. It omits details like output format or error cases, but this is acceptable for a simple data tool.

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

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

Three short sentences deliver the output definition, the use case, and the cost without wasted words. The most important information is front-loaded.

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

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

For a one-parameter tool with no output schema, the description covers the return values (7d/30d volatility and today's range), the pricing, and the use case. Nothing essential is missing for an agent to call it correctly.

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

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

The schema already fully documents the single symbol parameter with an example, so description-level parameter detail is not critical. The description's 'any USDT perp' phrasing adds only slight scope clarification 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?

Description states exactly what the tool computes: realized volatility for USDT perpetuals, with 7d and 30d annualized values and today's range. This distinguishes it from the many sibling get_* market tools, and the name reinforces the resource.

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

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

Explicitly labels the tool as a position-sizing input, which tells an agent when this metric is relevant. It does not name sibling alternatives or state when not to use it, but the use-case guidance is clear for a one-purpose metrics 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?

With no annotations, the description carries the burden and does well: it discloses cost ($0.02 USDC), network (Solana mainnet), data source (Helius enhanced), and output parsing fields. It doesn't cover rate limits or error behavior, but for a read-only wallet fetch this is strong.

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 filler; the core purpose is front-loaded and the second sentence adds only the essential cost/network caveat. Every part 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?

Without an output schema, the description compensates by listing the main returned fields and warning about cost. It is mostly complete for a simple wallet activity query, though pagination/ordering details and invalid-wallet behavior are not specified.

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 wallet and limit. The description adds the notion of recency and human-readable parsing but no parameter-specific detail beyond the schema, so the baseline 3 applies.

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

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

States a clear verb+resource: fetching recent transactions for any Solana wallet, and enumerates parsed fields (type, protocol, description, fee, failures). The activity focus distinguishes it from siblings like get_wallet_holdings, though it doesn't name alternatives explicitly.

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

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

Usage is implied: an agent should call this when it needs recent wallet transaction history. However, there is no explicit when/when-not guidance or mention of alternatives such as get_wallet_holdings.

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

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

With zero annotations, the description carries the full burden and does it well: it discloses the exact per-call cost ($0.008 USDC), the payment rail (x402), the network (Solana mainnet), and the data provider (Helius DAS). This is meaningful behavioral context beyond the name. It omits failure modes and rate limits, but the cost disclosure is the critical behavioral trait for a paid tool.

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

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

Two tight sentences with zero filler. The core content is front-loaded in the first sentence, and the cost disclosure earns its place in the second. Every word adds information.

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

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

For a one-parameter read tool, the content enumeration and cost disclosure cover a lot. However, there is no output schema, so the description doesn't hint at return structure or pagination, and it gives no guidance on alternatives like get_wallet_activity. These are notable gaps given no annotations exist to fill them.

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 the 'wallet' parameter already documented as a base58 Solana address. The description adds no parameter-level detail beyond confirming the Solana context, so the schema carries the load. Baseline 3 is appropriate.

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

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

The description states the resource (Solana wallet holdings) and precisely enumerates what's returned: native SOL, SPL tokens with USD values, and NFT count via Helius DAS. This content spec makes it distinguishable from siblings like get_wallet_activity or get_token_holders, though it never names them explicitly.

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

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

No when-to-use or when-not-to-use guidance is provided, and no alternative sibling tools are named. The cost disclosure ($0.008 per call) implicitly signals this is a paid call to use judiciously, but the description doesn't help an agent choose between this and wallet- or token-related siblings.

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

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

Since no annotations are provided, the description carries the full disclosure burden. It transparently discloses the paid nature of the call, including exact cost and payment rail ($0.02 USDC via x402 on Solana mainnet), and explains the data source and output categories. It does not fully describe return shape or time window, but the core behavioral context is present.

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 filler. The first sentence front-loads the core functionality and outputs; the second adds essential cost/payment information.

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

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

For a read-only tool with one required parameter, the description plus schema covers inputs, output categories, data source, and cost. The lack of an output schema is mildly mitigated by the listed output fields, though exact response structure and pagination are not specified.

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

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

The schema already documents all three parameters with 100% coverage, including symbol, limit, and min_usd. The description's mention of a USD threshold reinforces min_usd but does not add materially new parameter semantics 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 identifies a specific resource: large prints from the live trade tape for any USDT perp. It also enumerates the tool's outputs (buy/sell totals, net flow, dominant side), making it easy to distinguish from sibling market-data tools.

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

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

No explicit when-to-use guidance or alternative tool comparisons are provided. The agent must infer the tool's purpose from the name and description alone, with no exclusions, prerequisites, or selection conditions.

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

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

With no annotations, the description carries the behavioral disclosure burden. 'List' implies a read-only operation and 'Free' discloses a cost-related trait, but the description does not explicitly mention absence of side effects, authentication needs, rate limits, or the response format. For a zero-parameter tool this is minimally sufficient but not rich.

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

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

The description is one short sentence that front-loads the key 'Free' signal and states the action and scope immediately. Every word earns its place with no filler or redundancy.

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

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

For a zero-parameter listing tool with no output schema, the description is largely complete: it tells the agent what will be listed and in what currency. It does not spell out the exact return structure, but the expected result is simple enough that the agent can invoke it confidently.

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 properties, so the schema already fully describes all inputs. The description does not need to add parameter semantics, and with 0 params the baseline is 4.

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

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

The description uses a specific verb ('list'), a precise resource ('all agentfeed tools'), and a unit ('USDC prices'), so the agent knows exactly what the tool returns. It also clearly differentiates from the many sibling 'get_*' tools, which fetch individual market or metric data rather than an overall tool pricing list.

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

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

There is no guidance about when to use this tool versus alternatives, such as using it to check tool pricing before selecting another tool. The description only states what it does, not the conditions that would make it the right choice.

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