AgentFeed

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

Annotations already indicate read-only, non-destructive, idempotent behavior, and the description adds valuable behavioral details beyond that: decimals/symbol are read live from the contract to avoid magnitude errors, ENS is only trusted with two-resolver agreement, unsupported chains are refused, and the call costs 0.002 USDC. This gives an agent confidence in correctness 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?

The description is front-loaded with the core purpose, then each sentence adds distinct value: decimal correctness, ENS safety, chain safety, and cost. There is no filler or repetition of the title or schema.

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 three-parameter read-only tool with a full input schema and an output schema, the description covers chains, address resolution, token selection, native ETH behavior, error handling, and cost. 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics: omitting token returns native ETH balance, known tickers are accepted, and contract decimals are not assumed. This clarifies token behavior beyond the schema's bare descriptions.

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

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

The first sentence identifies a specific action and resource: returning ERC20 or native ETH wallet balances for a 0x address or ENS name on Base or Ethereum mainnet. This is more specific than the title and distinguishes it from related wallet tools like get_wallet_activity or get_wallet_holdings by focusing on balance and chain scope.

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

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

The description implies usage context through address formats, supported chains, and token options, but it never explicitly says when to choose this tool over an alternative. With a long sibling list, explicit routing would strengthen this dimension.

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

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

Beyond annotations (readOnly, openWorld, idempotent, non-destructive), the description adds substantial behavioral detail: returns both units, optional fields (base fee, priority fee, block number) dependent on node availability, three-node fallback, keyless access, and the exact cost of 0.001 USDC per call via x402. These are meaningful operational facts that affect how an agent plans and budgets the call.

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

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

The description is front-loaded with the essential payload, then gives a brief rationale for dual units, followed by infrastructure and cost. Each sentence contributes distinct value – no filler. The length is justified by the need to communicate fallback behavior and metering.

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 tool with a rich output schema, the description covers all relevant non-schema information: chain, units, optional fields, source reliability, keyless nature, and cost. The output schema handles return-value details, so nothing an agent needs to decide whether to call this tool and what to expect is missing.

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

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

The tool has zero parameters)Skip, so the schema is trivially fully covered and there is nothing to document. Per the baseline for 0 params, a score of 4 is appropriate; the description adds no parameter semantics because none are needed.

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

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

The description clearly identifies the resource (Base gas price on chain 8453) and specifies the returned fields (gwei, wei, base fee, priority fee, block number). It does not explicitly name a sibling tool to distinguish from, but the chain ID and unit duality make its purpose concrete. A 5 would require an explicit sibling contrast such as 'use get_priority_fees for priority fee breakdowns.'

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 the tool: when needing base gas price in either gwei or wei. It explicitly explains that both units are returned because they are the same question, discouraging redundant calls for the other unit. It also provides operational context (keyless RPC, no key rotation, cost per call) but does not mention alternative tools or exclusion conditions, so it falls short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds a genuinely non-obvious behavioral fact: it costs 0.01 USDC per call via x402 on Solana or Base, and it enumerates the three things returned. That payment requirement is material context an agent cannot get from the 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-loaded with what is computed and followed by the cost. No filler; every clause (premium/discount, contango/backwardation, funding context, price) carries information.

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

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

With an output schema present, return values need not be explained, and the description still summarizes them plus the payment requirement. The remaining gap is routing guidance versus the funding/perp siblings, but for a single-optional-param paid tool it 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 coverage is 100% with a single optional symbol parameter and an inline example plus default, so the schema does the heavy lifting. The description only adds that the pair is a 'USDT pair', which lightly reinforces valid input but adds little 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?

States a specific computation on a specific resource: perp-vs-spot basis for USDT pairs, returning premium/discount %, contango/backwardation, and funding context. It is clearly distinct from generic price tools, but it does not explicitly differentiate itself from funding-oriented siblings like get_funding_rate despite referencing 'funding context'.

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

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

There is no when-to-use guidance and no alternatives named among the many siblings (get_funding_rate, get_spread_arb, get_perp/get_spot). The only directive is implicit in the cost note, which tells the agent a payment is required but not when this tool is the right choice.

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

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

Beyond the annotations (read-only, idempotent, non-destructive), the description adds critical behavioral context: the multi-source fallback mechanism, the null confidence/publish_time behavior depending on the serving source, and the 0.001 USDC per-call cost. These are not covered by annotations and significantly inform an agent's invocation decisions.

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 the core purpose front-loaded in the first clause. The second sentence packs the fallback/null behavior and cost into a compact, information-dense statement with no redundancy.

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

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

For a zero-parameter, read-only tool with an existing output schema, the description covers the essential non-schema context: what the null fields mean, the source fallback, and the per-call monetary cost. An agent has everything needed to decide whether and how to call this tool.

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

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

There are zero parameters and 100% schema description coverage, so the input schema fully documents the parameter surface. The baseline of 4 applies; the description adds no parameter-related meaning, but none is needed.

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

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

The description states a specific verb+resource: 'Live BTC/USD spot price' and names the exact data sources (Coinbase, Kraken, Pyth Hermes fallback). This clearly distinguishes it from sibling tools like get_eth_price or get_spot, leaving no ambiguity about the asset or scope.

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

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

Usage is implied by the asset name and description, but there is no explicit guidance on when to choose this tool over alternatives. The cost and multi-source nature provide context, but no alternatives or exclusions are mentioned, so the guidance remains inferred rather than stated.

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

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

Annotations already mark the tool read-only, idempotent, and non-destructive, and the description adds meaningful behavioral context: it costs 0.01 USDC per call payable via x402, is time-sensitive ('active NOW'), and returns a structured cascade summary with severity levels. This goes well beyond the structured metadata.

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 carry the full scope, output shape, empty-case behavior, sibling routing, and cost. It is front-loaded with what the tool does and contains no filler or redundant restatement of the schema.

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 detector with three optional parameters, an output schema, and safe annotations, the description is complete: it covers the target symbols, the returned fields, the no-result case, the cost, and the correct alternative tool. Nothing essential is missing for an agent to 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 input schema already documents all three parameters with descriptions and defaults, so schema coverage is 100%. The description does not need to restate parameter semantics, but it also does not add extra detail about how the parameters affect cascade detection beyond what the schema provides.

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

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

The description states a specific verb-plus-resource purpose: it detects and returns currently active liquidation cascades for exactly five majors. It clearly distinguishes itself from get_cascade_scan by naming the broader perp universe as the alternative, so an agent can tell the tools apart without inspecting schemas.

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 context is explicit: this tool is for the 5 majors, and if the agent needs every USDT perp across 3 exchanges it should use get_cascade_scan. It also clarifies the empty-array meaning, so an agent knows how to interpret a no-cascade result.

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

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds substantial behavioral context beyond them: the tool DECLINES when history is too thin rather than guessing (and says why), every answer embeds self-settling instructions, the calibration provenance (28-day tape, 1.4M liquidations, 799 symbols) that cannot be reconstructed, the 0.02 USDC cost, and the free record location. These are exactly the behavioral traits an agent needs and the annotations do not carry.

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

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

The description is front-loaded with the defining trait ('FORWARD-LOOKING and not a description of what already happened') and the core return value. Every subsequent sentence earns its place: calibration provenance, self-settling transparency, declination behavior, record URL, and cost. Despite its length, there is no filler — each 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?

Given the output schema exists and annotations cover safety (read-only, idempotent), the description covers everything else an agent needs: what the probability means, when it declines, how to settle/verify, where the settled record lives, and how much it costs. The pricing and declination behavior are critical operational details that would otherwise be entirely absent.

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

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

Schema coverage is 100% — both 'symbol' (with default SOL) and 'symbols' (comma-separated, max 20) are fully documented in the input schema. The description adds no parameter-specific semantics beyond that, so the baseline of 3 for high schema coverage applies. This is acceptable since the schema already carries the parameter 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 states a precise, specific computation: 'the probability that a symbol will liquidate more in the NEXT 15 minutes than its own 90th-percentile 15-minute window.' It explicitly distinguishes itself as FORWARD-LOOKING 'and not a description of what already happened,' which separates it from history siblings like get_cascade_history and get_liq_history. An agent can tell this tool apart from its siblings without opening 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 description gives clear context: this is for forward-looking liquidation probability, not historical reconstruction, and it explains the declination behavior ('DECLINES rather than guessing') and the per-call cost, which informs when it should be invoked. However, it never explicitly names alternatives — notably get_cascade_forecast_free, which is presumably the no-cost route — so it stops short of 5, which would require explicit when-not/alternative 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by explaining the free nature, the scope (SOL only), and the purpose of calibration checking, which goes beyond the structured metadata.

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

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

Two sentences, front-loaded with the key facts: 'FREE taster' and 'full-quality liquidation forecast for SOL.' No filler, every word contributes to understanding the tool's scope and purpose.

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

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

The description is complete for an agent to select and invoke correctly. It explains what, scope, and why to use it. The output schema exists, so return format details are not required. It fully covers the free vs. paid distinction and the use case.

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

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

With zero parameters and 100% schema coverage (empty schema), the description has no need to explain parameters. The baseline for 0-param tools is 4, and the description appropriately omits any param 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 clearly states it is a free liquidation forecast for SOL, explicitly noting it is the 'full-quality' version with 'no delay and nothing withheld.' It distinguishes itself from the paid sibling get_cascade_forecast by being free and limited to SOL, making its purpose unambiguous.

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

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

It explicitly tells when to use: 'Use it to check the calibration before paying for coverage of the other ~345 symbols.' This implies the alternative (get_cascade_forecast) for broader coverage and provides clear context for selection.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior, so the description's added value comes from disclosing the paid nature: 'Costs 0.03 USDC per call (x402, USDC on Solana or Base)' — critical operational knowledge an agent needs before invocation. It also adds the data-origin detail ('reconstructed from our own tape') and the 72h lookback cap, neither of which is in the structured fields.

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

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

Three sentences with each earning its place: the first states purpose and output shape, the second provides the temporal contrast with the live endpoint, and the third discloses cost and payment rails. Critical payoff information (pricing, scope) is front-loaded early in 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?

With a full output schema, 100% parameter coverage, and safety annotations, the description need not explain return shapes or idempotency. It covers purpose, data source, time bounds, cost, and the main alternative. The one gap is that it does not clarify how it differs from other historical liquidation tools in the sibling set, which is a plausible source of agent confusion.

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 every parameter (gap_s, hours, scope, symbol, min_usd) is already documented with defaults and examples in the schema. The description adds conceptual framing (clustered same-side flush events, peak print) that helps interpret gap_s and min_usd, but provides no per-parameter guidance beyond schema parity, matching the baseline of 3 for high 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 names a specific resource and operation: 'Liquidation cascade history: past clustered same-side flush events reconstructed from our own tape,' and specifies output contents (start/end, prints, USD total, peak print) and temporal bounds (up to 72h back). It also distinguishes itself from the live endpoint by contrasting 'what is happening NOW' with 'what already happened,' which separates it from real-time cascade 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 an explicit when/when-not: use /api/cascade for current activity and this tool for historical events. However, it only contrasts against one live endpoint and does not route among the many historical liquidation siblings (get_liq_history, get_recent_liquidations, get_cascade_scan), leaving some selection ambiguity in the broader sibling family.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the paid nature (0.05 USDC via x402), the unique data provenance (Bybit unthrottled tape), and the returned fields. It does not discuss rate limits or pagination, but those are not critical given the output schema and annotations.

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

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

Three sentences, each earning its place: the first defines the scan scope, the second justifies the data uniqueness, and the third lists outputs and cost. The key qualifier 'FULL-UNIVERSE' is front-loaded, 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?

For a read-only scan with three optional, well-documented parameters and an output schema, the description is complete: it states scope, output fields, cost, and data provenance. The only minor gap is explicit sibling routing, but that is not necessary for a correct 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 covers all three parameters (window, min_usd, min_events) with descriptions, so the baseline is 3. The tool description adds no parameter-specific meaning beyond the schema, but it does not need to because schema coverage is 100%.

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 'FULL-UNIVERSE cascade scan' and immediately specifies the verb ('detects liquidation cascades'), resource ('every USDT perp we record on Bybit, OKX and Binance'), and scope ('not just majors'). This clearly separates it from narrower liquidation tools like get_last_liquidation or get_cascade_alert, 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?

The description implies when to use this tool – when a full-universe cascade scan is needed rather than a major-only or single-symbol view – but it never explicitly states when to prefer a sibling or when not to use it. It provides clear context but no exclusions or alternative 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond the annotations by disclosing the per-call cost of 0.005 USDC, the x402 payment mechanism, and the fact that the quote reflects a real executable price rather than an index price.

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

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

The description is concise and front-loaded: the first sentence states the core purpose and outputs, and the second sentence adds the important cost and network details. Every sentence earns its place, with no filler or repetition of schema 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?

For a three-parameter read-only quote tool with full schema coverage and an output schema, this description is complete. It covers what the quote returns, the key distinction from index prices, the cost, and the payment rail, which is everything an agent needs to decide whether and how to invoke the tool.

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

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

Schema description coverage is 100%, so input_mint, output_mint, and amount are already documented with meaningful descriptions such as 'raw base units' and 'base58'. The description reinforces that any SPL pair is supported but does not add substantial parameter-level 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 the verb-resource pair: retrieving a Solana DEX quote from Jupiter for any SPL pair, and enumerates the key outputs (output amount, price impact, route, slippage). It distinguishes itself from index-price tools by explicitly stating this is the real executable price, though it does not name a specific sibling tool to differentiate from.

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 this tool is appropriate: when an executable on-chain DEX price, rather than an index price, is needed for an SPL pair. However, it provides no explicit when-not-to-use guidance and does not mention alternatives like get_exit_quote or get_spot, leaving the routing decision 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?

The description goes far beyond the annotations. It discloses the aggregation across seven venues, the return structure (lead figure plus all answering venue quotes), the deterministic ordering rule, and the per-call cost and payment rails. These are critical behavioral details that the annotations (readOnly, idempotent, openWorld) do not capture. No contradiction with annotations.

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

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

The description is somewhat long but every sentence carries essential information: the core price, the venue list, the return format, the deterministic ordering, and the cost. It is front-loaded with the primary purpose and then adds critical operational details. Slightly more compact than ideal, but 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 the zero-parameter nature and the presence of an output schema, the description fully covers what an agent needs: what the tool returns, how venues are aggregated, determinism, and cost. There is no ambiguity about invocation or expected behavior. The description is complete for a zero-param query tool.

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

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

The tool has zero parameters and the schema is empty, so there is nothing for the description to explain. The baseline for zero parameters is 4, and the description appropriately omits any parameter discussion since none exist. No additional semantic burden 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 states a specific verb and resource: 'ETH spot price in USD', and explicitly details the aggregation across seven named venues. It distinguishes itself from siblings like get_btc_price and get_sol_price by focusing on ETH and its multi-venue nature. The purpose is unambiguous and immediately clear.

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

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

While it doesn't explicitly name alternative tools or say 'use this when...', the description makes the use case self-evident: obtaining a robust, multi-venue ETH spot price. It implies usage when a single-exchange quote is insufficient, but it doesn't explicitly contrast with get_spot or get_market_snapshot. Clear context, though no explicit exclusions.

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

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

Annotations already state readOnly/openWorld/idempotent. The description goes well beyond them by disclosing that data is 'computed from the tape at request time, nothing hardcoded,' that it is free, and that the status vocabulary distinguishes events like 'a router refusal and an empty book' as different facts. These are behavioral specifics not derivable from the annotations.

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

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

The description is a dense single paragraph covering many distinct aspects (measurement methodology, corroboration rule, status vocabulary, control design, row counts, covered symbols, cadence) with no filler. It is front-loaded with 'FREE' and the core question about overhang, though a bulleted structure would slightly improve scannability.

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 informational tool with an output schema, the description is complete: it explains what is returned, why the tool exists, how the data is computed, and when to use it relative to the paid sibling. Nothing an agent needs to correctly select and invoke 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?

The tool has zero parameters and schema coverage is trivially 100%, so the baseline of 4 applies. The description correctly contains no parameter information because none is needed for invocation.

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

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

The description clearly defines the tool as returning the methodology and live-computed data behind exit liquidity measurements, with specific phrases like 'Returns what is measured' and 'the corroboration rule in plain terms.' It distinguishes itself from the paid sibling get_exit_quote by being explicitly 'FREE' and framed as the precursor, so an agent can tell it apart without opening schemas.

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 it: 'Read this before paying for get_exit_quote, and to check the claim rather than trust it.' This both identifies the alternative tool and the condition that selects this one, leaving nothing 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?

The description goes far beyond the readOnlyHint annotation, revealing the bisection method, six-consecutive-observation rule, fallback behavior, distinction between router refusal and missing route, zero bad debt caveat, and the 0.02 USDC cost. This is exceptional 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 dense and information-rich, with core purpose front-loaded. It is somewhat long, but each clause adds critical context about methodology, edge cases, or cost. The structure could be slightly improved with paragraph breaks, but it remains efficient.

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

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

Given the presence of an output schema and annotations, the description covers all necessary contextual elements: methodology, interpretation caveats, fallback behavior, cost, and the distinction between routing failures. Nothing critical is missing for an agent to select and invoke 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% with good parameter descriptions. The description adds extra meaning about size_usd (nearest measured clip, never interpolated) and implies symbol must be from covered list by referencing get_exit_method. This supplements the schema meaningfully.

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

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

The description clearly states the tool measures actual exit liquidity for seized collateral versus oracle price, with a specific verb and resource. It distinguishes itself from generic liquidation or quote tools, but doesn't explicitly name the sibling it differs from.

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: when a liquidator needs to know realizable value on Kamino reserves. It also references get_exit_method for methodology, showing awareness of related tools, though it doesn't explicitly state when NOT to use this tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds minimal extra behavioral context: it is free and includes a classification. It does not contradict annotations, but it does not disclose rate limits, update frequency, or other operational nuances.

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

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

The description is extremely concise and front-loaded: it states the data source, scale, output characteristic, and cost in two short sentences. Every word adds value with no redundancy.

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

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

For a zero-parameter, read-only tool with an output schema and comprehensive annotations, the description is sufficient for an agent to understand what the tool provides and to invoke it correctly. Missing usage guidance is captured under usage_guidelines, not completeness.

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

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

The tool has zero parameters)Skip, and schema coverage is 100% with an empty properties object. There are no parameters requiring additional semantic explanation, so the baseline of 4 applies; the description need not add parameter detail.

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

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

The description identifies the specific resource (Crypto Fear & Greed index) and adds the scale (0-100) and classification aspect, making the purpose clear. It lacks an explicit verb like 'returns' or 'retrieves', and it does not explicitly differentiate itself from sibling tools, though the resource is unique.

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 no guidance on when to use this tool versus alternatives. The word 'Free' hints at a cost advantage but does not state a use case, prerequisites, or exclusions. An agent would not know when this is preferred over other data tools.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the description only needs to add extra context. It adds useful behavioral detail: the data is free, machine-readable, from the public exchange feed, and includes self-settlement instructions and covered symbols.

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 with the key 'FREE' fact and main content front-loaded. The repetition of 'Free' at the end is a minor redundancy, but overall it is efficient.

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

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

For a parameterless, read-only tool with an output schema, the description is sufficiently complete. It states what is returned, the data source, the free nature, and the correct usage order, with no important gap for an agent selecting and invoking the tool.

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

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

The tool has zero parameters and 100% schema description coverage, so the baseline of 4 applies. There are no parameters for the description to explain.

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

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

The description clearly identifies the tool as returning the exact question a forecast answers, including machine-readable settlement details and the list of covered symbols. It lacks an explicit verb like 'returns' and doesn't name a differentiating sibling, but the purpose is unambiguous enough.

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 'Read this before building on the forecast' explicitly gives a precondition for using this tool, and the 'FREE' marker signals a no-cost entry point. It doesn't discuss when not to use the tool or point to alternative tools, but the context is clear.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description discloses valuable behavioral details: forecasts are written before the window opens, settled from the exchange public feed afterward, and raw rows are returned for independent recomputation. It also notes the output fields and that the tool is free, giving agents a strong safety and trust profile.

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

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

The description is front-loaded with the key fact ('FREE: the live track record of this miner') and contains useful details, but it is slightly wordy with the repeated 'Free' at the end and a somewhat rhetorical backtest sentence. It earns a high score but loses a point for minor redundancy.

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

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

Given the read-only annotations, optional parameters, and existing output schema, the description covers what an agent needs: what the record is, how it was produced, what metrics are returned, and why it can be trusted. No critical call-invocation information appears to be 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 coverage is 100% and both parameters have clear descriptions. The tool description adds general context about raw rows being returned, but it does not contribute meaningfully beyond the schema's own parameter documentation, so the baseline score of 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 names a specific verb-resource pair ('get the live track record of this miner') and clearly states what is returned: settled count, Brier skill, coverage, calibration error, and reliability curve. It also distinguishes the tool from a backtest, so an agent can understand what this record is and is not without opening 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 description gives clear context for when this tool is appropriate: when you need a verifiable live track record rather than an author-computed backtest. It explicitly contrasts it with backtests ('this is not that') but does not name specific sibling tools or provide a full when-to-use vs alternatives matrix.

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

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

Annotations already cover readOnly/idempotent/openWorld/no-destructive, so the safety profile is set. The description adds genuinely new behavioral context: a per-call cost of 0.01 USDC via x402 on Solana or Base, which is important for an agent deciding whether to invoke it. It does not mention rate limits or latency, keeping it short of a 5.

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 capability and venues before the billing detail. No filler; every clause carries distinct information (coverage, outputs, cost, payment rails).

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

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

With an output schema present, the return shape need not be explained, and the one parameter is fully covered by the schema. Purpose, venues, and cost are all stated, so the definition is essentially complete; only the routing against sibling funding tools is left implicit.

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

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

Schema coverage is 100% with a single well-documented 'symbol' parameter including an example and default. The description adds nothing about symbol handling, so the baseline of 3 applies — the schema does the work and the description neither compensates nor detracts.

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 verb+resource ('funding rate for ANY USDT perp') and a precise scope: three named venues (Bybit, OKX, Hyperliquid) plus the derived outputs (cross-venue spread, crowding read). This implicitly distinguishes it from the many single-venue funding siblings, but it never names an alternative, so an agent must infer the distinction.

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 'in one call' implies the multi-venue use case versus per-venue calls, and the price note signals it is a paid convenience tool. However, there is no explicit when-to-use/when-not and no sibling is named, leaving the choice against get_funding_rate, get_funding_extremes, etc. 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?

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations by disclosing the 0.02 USDC cost, x402 payment mechanism, and that USDC is accepted on Solana or Base. This is meaningful behavioral information the annotations do not convey.

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

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

Three concise sentences, each earning its place: scope and return fields, interpretation/use case, and cost. The most decision-relevant information is front-loaded with no filler or repetition.

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

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

Given the tool's simplicity (0 required parameters) and the presence of an output schema, the description covers the essential context: what is returned, what it means, and the cost. It does not explicitly route to sibling tools, but nothing an agent needs to correctly invoke it 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%; both 'limit' and 'min_turnover_usd' are already fully described in the schema with defaults and ranges. The description does not add parameter-specific meaning beyond that, so the baseline score of 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?

Description opens with a concrete action and resource: 'Funding rate extremes across every Bybit USDT perp'. It explicitly lists the returned metrics (annualized %, 24h price move, open interest), making the tool's scope and output unmistakable and distinct from generic funding-rate 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 clearly states the intended use case: surfacing the most crowded trades, with 'crowded shorts are squeeze candidates'. This gives an agent strong context for when to use it, though it does not explicitly name sibling alternatives or state when not to use it.

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

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

Annotations already cover read-only, open-world and idempotent traits, so the description earns credit for adding what they cannot: a per-call price (0.005 USDC via x402 on Solana or Base). That payment/cost disclosure is genuinely useful behavioral context an agent needs before calling. It stops short of mentioning rate limits or history depth beyond 200.

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

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

Three sentences, front-loaded with the purpose and result fields, then cost. 'What the carry has actually been' is slightly decorative but reinforces intent rather than wasting a slot.

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?

An output schema exists, so return values need not be explained, and pricing is covered. What is missing is sibling differentiation and any statement of history boundaries beyond the 200-interval cap, leaving the agent under-equipped to choose this over get_funding_rate.

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 schema already documents limit (1-200, default 30) and symbol (default SOLUSDT). The description's 'up to 200 intervals' and 'any USDT perp' merely echo that, adding no syntax or format meaning. Baseline 3 applies when the schema carries the load.

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 verb and resource ('funding rate history for any USDT perp') and even enumerates the returned quantities, so the purpose is unambiguous. However, it never distinguishes itself from the several funding-named siblings (get_funding_rate, get_funding_pulse, get_funding_extremes, get_funding_cross), which is where an agent is most likely to misfire.

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 when-to-use, when-not, or alternative named. The 'history' framing implies a retrospective use case, but with four sibling funding tools the absence of routing guidance is a real gap.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive; the description adds the critical behavioral fact that each call costs 0.001 USDC via x402, which matters for agent cost decisions. It also clarifies the return shape (5 largest rates with venue, 8h rate, OI, price move), going beyond annotation coverage. No contradiction.

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

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

Three tight sentences, with the trigger condition front-loaded, the output contract in the middle, and the cost warning at the end. Every sentence contributes new information; 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?

For a zero-parameter, read-only tool with an output schema, the description covers trigger, output fields, scope universe, and cost. Nothing an agent needs to decide whether to call it or understand its result 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, giving 100% coverage by definition. With zero parameters, the description cannot add parameter meaning, but it doesn't need to, so the baseline 4 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 specific verb ('get') and a specific resource ('most extreme funding rates right now'), then precisely defines the return: the 5 largest absolute annualised rates across Bybit USDT perps with venue, 8h rate, OI, and 24h move. This clearly differentiates it from sibling funding tools like get_funding_rate or get_funding_history.

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

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

Opens with an explicit trigger: 'Use when an agent needs the most extreme funding rates right now.' The phrase 'One call, not a full screen' implies alternatives exist for broader analysis without naming them, and the Bybit USDT perp universe scoping prevents misuse for other venues. It lacks explicit 'use X instead' exclusions but the condition is clear.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new operational context: a per-call charge of 0.002 USDC settled via x402 on Solana or Base, plus the per-venue interval normalization. It does not cover rate limits or failure modes, but the paid-call disclosure is meaningful.

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?

Front-loaded with the core purpose, then the no-symbol fallback, then pricing. The field enumeration in the middle is dense but each item is informative; nothing is redundant padding.

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-optional-parameter read tool with an output schema and full annotation coverage, the description supplies what structured fields cannot: venue coverage, default-symbol behavior, and the payment model. Return values need not be explained given the output schema.

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

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

Schema coverage is 100% and the single 'symbol' parameter's format and omission behavior are documented in the schema itself. The description's field list describes outputs rather than the parameter, so it adds little semantic value to the parameter beyond the schema 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?

States a specific verb+resource ('funding rate for any USDT perp') with the exact venue scope (Bybit, OKX, Hyperliquid) and enumerates the returned fields. It does not, however, distinguish itself from the many funding siblings (get_funding_cross, get_funding_history, get_funding_pulse, get_funding_extremes), so an agent must infer the difference.

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 fallback behavior ('Without a symbol, SOL and BTC from Hyperliquid with open interest') and a cost signal, which implies usage but never states when to choose this over the other funding tools. No explicit when-not or alternative is named.

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

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

Annotations already declare it read-only, open-world, idempotent, and non-destructive; the description adds valuable operational context: a hard cost of 0.005 USDC per call, payment via x402, and accepted USDC networks (Solana or Base). It also clarifies the payload shape (percentiles plus EMA and recommendation).

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, both load-bearing. The data content is front-loaded, and the cost/payment details are tucked into a single compact second sentence. There is no filler or repetition of the annotations.

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-input, read-only tool with an output schema, the description covers what is returned, in what unit (SOL), and the key operational constraint (cost and payment rails). No other parameter, prerequisite, or return-value detail is necessary for an agent to 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 baseline is 4. The description adds no parameter semantics, but none are needed; instead it clarifies the data scope and units an agent can expect without any inputs.

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

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

The description states exactly what the tool returns: Jito bundle tip floor percentiles p25–p99 in SOL, an EMA p50, and a landing recommendation. This goes well beyond the title 'Jito tip floor' and distinguishes it from the many other market-data getters in the sibling 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 explicit guidance about when to call this tool versus alternatives such as get_priority_fees or pricing. The phrase 'what landed bundles are actually paying' implies a use case, but the description never states the intended context or conditions that should select this tool.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond annotations: the 15-minute delay, the limited asset universe, and the free/taster nature of the data.

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

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

The description is short and front-loaded with the key facts. The word 'Free' appears twice, which is slightly redundant, but the overall structure is efficient and scannable.

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

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

With no parameters, a rich output schema, and strong annotations, the description covers the essential context: what data is returned, for which assets, with what delay, and when to use the real-time alternative. It is complete for a no-argument read-only tool.

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

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

There are zero parameters and schema description coverage is 100%, so the baseline is 4. The description appropriately focuses on scope and data freshness rather than parameter details, since none exist.

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 ('last liquidation'), the specific assets covered (SOL, BTC, ETH, XRP, DOGE), and the data delay. It also distinguishes itself from get_recent_liquidations by explicitly pointing to that sibling for real-time data.

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

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

It names the alternative tool (get_recent_liquidations) and the condition for choosing it ('Real-time'). The 'FREE taster' phrasing implies this is for a free, delayed sample, though it does not explicitly state 'use this when you need delayed data'.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the bar is lower, and the description adds genuinely useful context beyond them: a per-call cost (0.05 USDC, x402 on Solana or Base) and the data provenance ('real liquidation prints, not entry-price estimates'). This tells the agent about payment and data quality, which annotations do not.

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?

Front-loaded with the core purpose, then provenance and cost in separate short clauses; every sentence carries information. Slightly dense but no wasted phrasing.

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

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

With an output schema present, return values need not be explained, and annotations cover the safety profile; the description still contributes cost and data-source context. Only the lack of sibling routing keeps it from fully complete.

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

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

Schema description coverage is 100%, so the schema already documents hours, symbol, and buckets, making 3 the baseline. The description only loosely echoes 'last N hours' and 'price zone' without adding syntax, units, or range guidance 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?

States a specific resource and the exact dimension it aggregates on ('Liquidation heatmap by PRICE LEVEL'), which cleanly separates it from the many sibling liquidation tools that report history, pulse, leaders, or stats. The output content is spelled out (USD, prints, long/short split per zone, hottest zone flagged).

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 'last N hours' framing implies when the tool is relevant (recent leverage flushes), but there is no explicit when-to-use/when-not or routing to alternatives like get_liq_history or get_liquidation_leaders. Usage is left to inference given the crowded liquidation-tool family.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive, which already cover safety. The description adds valuable context: cost per call (0.05 USDC via x402), the claim about Bybit being the only complete liq tape (implying data source), and the 7-day lookback limit. These go beyond annotations and help set expectations for cost and data availability.

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

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

The description is a single, information-dense sentence that front-loads the core output (time-bucketed liquidation history) before adding scope and time constraints. It then provides valuable context on data uniqueness and cost. Every clause earns its place, though it could be slightly more structured for readability.

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

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

Given the tool's complexity (multiple parameters, scoping options, output schema) and the rich annotations, the description covers the key operational facts: time window, scope, cost, and data source uniqueness. The output schema handles return structure, and annotations cover safety. Missing minor things like example usage or authentication specifics, but not critical.

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

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

Schema description coverage is 100%, so the schema already explains each parameter (hours, scope, symbol, bucket_min). The description adds no extra parameter-level details beyond what's in the schema, but the schema's descriptions are sufficient. It clarifies the 'all' scope and default symbol, but that's already in the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb ('get') and resource ('liquidation history') with detailed output contents: time-bucketed totals, long and short USD, prints, biggest print per bucket, for a symbol or whole universe. It clearly distinguishes from siblings like get_last_liquidation (single print) and get_recent_liquidations (recent trades), making it unique among the many liquidation-related 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 implies when to use: for historical liquidation data up to 7 days back, as opposed to real-time or single-liquidation tools. It mentions the whole-universe option and the 7-day limit. However, it doesn't explicitly say 'when not to use' or name alternative tools for other liquidation needs, but the context is clear enough for an agent to pick this for historical analysis.

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

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

The annotations already declare the tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond that: the response covers only the last 60 minutes, 'declines with the tape age if our recording is stale', and the call costs 0.001 USDC via x402 on Solana or Base. This cost and staleness disclosure is exactly the kind of operational behavior an agent needs before invoking.

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 redundant filler. The most important usage signal is front-loaded, and every remaining clause (output contents, staleness behavior, cost) 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?

For a parameterless, read-only tool with an output schema, the description is fully sufficient: it states when to call, what the response will contain, the time window, the staleness caveat, and the cost. No critical operational detail is missing for an agent to decide and invoke correctly.

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

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

The tool has zero parameters and schema coverage is complete, so there is nothing semantically ambiguous. Per the baseline for parameterless tools, the description does not need to add parameter detail; it already communicates the time window and output scope.

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

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

The description opens with a clear trigger ('Use when an agent needs to know what is being liquidated right now') and specifies the resource: the last 60 minutes of USDT perp liquidations across every recorded symbol. It also differentiates from siblings by naming the response contents (total USD, long/short split, prints, top 5 symbols), so an agent can distinguish it from get_last_liquidation, get_liq_history, or get_liq_heatmap.

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 'Use when' phrasing gives explicit context for when to call this tool, and the 60-minute window plus USDT perp scope clarifies its boundary. It does not explicitly name alternatives or state when not to use it, but the context is clear enough to route an agent correctly among the many liquidation-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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds valuable context beyond annotations: cross-venue data sources, the aggregation fields returned, and the 0.02 USDC fee with settlement rails. No contradictory behavioral claims are 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 compact and front-loaded, leading with the core purpose, then listing output fields, positioning, and cost. The rhetorical phrases like 'blowing up RIGHT NOW' and 'fastest read' add tone but not hard information, which keeps it from a perfect score.

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 read-only tool with an output schema and two optional, well-documented parameters, the description provides everything needed: source venues, per-symbol result dimensions, and the fee. Nothing an agent needs to call it correctly is clearly 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%, and both parameters (limit, window_min) already have clear descriptions in the schema. The tool description does not add further parameter nuance, but the schema carries the semantic weight.

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: top symbols ranked by liquidation USD across USDT perps on Bybit, OKX, and Binance, with per-symbol breakdown fields. It is unambiguous about what the tool returns, though it does not explicitly contrast itself with closely related 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?

The phrase 'fastest read on where leverage is being flushed' gives an agent a clear context for when to use this tool: quick liquidation-pulse monitoring. It does not spell out exclusions or alternatives, but for a simple read-only snapshot tool the implied usage is reasonably clear.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds a critical non-obvious trait: the call costs 0.004 USDC via x402 on Solana or Base. This is essential for an agent to know before invoking, as it involves a payment. It also details the output composition, which goes beyond the empty input schema, giving the agent context about the returned data structure.

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 exactly two sentences, with the first sentence front-loading the core resource and its contents, and the second adding the cost and execution details. Every word carries information—no fluff, no repetition. It is tightly structured and efficient.

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

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

For a no-parameter tool with an output schema (which presumably details the structure), the description already lists the major output components: timeframes, long/short split, largest liquidation, and exchange breakdown. It also discloses the fee and payment method. The only minor omission is nuance about x402 itself, but that is not essential to calling the tool correctly. The description is complete for an agent to decide and invoke.

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

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

The tool has zero parameters, so the schema provides no meaning to clarify. The baseline for a zero-parameter tool is 4. The description effectively explains what the tool returns, which is the only relevant semantic information. It does not need to add parameter-specific details since none exist.

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 liquidation aggregates for exactly 5 specified cryptocurrencies (SOL, BTC, ETH, XRP, DOGE) with concrete breakdowns (1h/24h totals, longs vs shorts, biggest print, per exchange). This distinguishes it from sibling tools like get_last_liquidation or get_liq_history, which focus on individual liquidations or historical data. The verb is implied by the name, but the resource and content are precise.

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

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

The description provides clear information about what the tool returns, which implies it should be used when an agent needs aggregated liquidation statistics for these five majors. However, it does not explicitly state when not to use it or mention alternatives. No exclusion criteria are given, so the agent must infer usage from the content. This is adequate but lacks explicit 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?

Annotations already establish read-only, idempotent, open-world, non-destructive behavior. The description contributes beyond them by disclosing the data source (Bybit), the specific payload (retail long/short account percentages with 1h/24h trend), and the cost/access model (0.01 USDC via x402 on Solana or Base), which is genuinely useful behavioral context.

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

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

Three tight sentences, front-loaded with the core resource and scope, then a punchy functional tag, then the cost. Every sentence earns its place with no redundancy.

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

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

For a 1-param read tool with an output schema and full annotation coverage, the description covers purpose, source, payload shape, and payment model. Return values need not be explained given the output schema, leaving little 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 single symbol parameter and its default are already fully documented. The description reinforces the 'USDT perp' constraint but adds no syntax or format detail beyond what the schema provides, 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?

Names a specific resource (long/short ratio) with the source (Bybit retail account percentages) and the trend granularity (1h and 24h), plus the scope (ANY USDT perp). 'The crowding gauge' adds a functional framing, but it does not explicitly distinguish itself from a nearby sibling like get_positioning.

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 only implied via 'The crowding gauge,' which hints at sentiment/crowding analysis, and the cost note signals a paid, deliberate call. There is no explicit when-to-use, when-not, or named alternative among the many funding/positioning siblings.

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

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

Annotations already establish that this is read-only, idempotent, and non-destructive, so the description's job is to add operational context. It discloses a non-obvious cost of 0.003 USDC per call and the x402/USDC settlement network, which is valuable beyond what annotations provide.

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

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

A single, front-loaded sentence communicates the data scope and the cost constraint without any redundancy. Every word contributes.

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

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

For a zero-parameter read-only snapshot with an output schema, the description covers the data scope and the only operational concern (cost). The output schema can handle structural return details, so nothing needed for a correct call is missing.

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

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

The tool has zero parameters and the schema fully covers that, so there is no parameter detail for the description to add. The zero-parameter baseline applies and is met.

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 names the aggregated resource (SOL+BTC prices, funding rates, Fear & Greed) and the verb is implicit in the tool name. It distinguishes this snapshot from single-metric siblings like get_btc_price, get_sol_price, get_funding_rate, 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?

'In one call' conveys that this is the consolidated choice when multiple market signals are needed, and the cost note adds a decision-relevant tradeoff. It does not explicitly name alternatives or exclusion conditions, but the context is clear.

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

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

Annotations already cover readOnly, idempotent, and non-destructive traits. The description adds valuable behavioral context: a cost of 0.02 USDC per call (x402, USDC on Solana/Base) and that it returns baseline_min_ago (exact age of the snapshot) plus funding and 24h price context. This goes beyond annotations without contradiction.

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

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

The description is a single, information-dense sentence that front-loads the core purpose and scope, then adds details on the baseline, context, and cost. It's efficient but slightly dense; splitting into two sentences would improve readability without adding length.

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

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

With an output schema present and annotations covering safety, the description provides sufficient context: the universe, spike definition, cost, and what the response includes (baseline age, funding, price context). No major gaps for a tool with one optional parameter.

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

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

The input schema has 100% coverage for the single 'limit' parameter, including a full description ('top N, 1-25, default 10'). The tool description doesn't add any parameter-specific meaning beyond the schema, so it stays at the baseline of 3.

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

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

The description clearly states the tool scans for open interest spikes across all Bybit USDT perps, defining 'spikes' as abnormal OI jumps against an earlier snapshot. This distinguishes it from siblings like get_open_interest (raw OI levels) and get_funding_* (funding rates) by focusing on anomaly detection with additional context.

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

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

The description implies when to use it: when the agent needs a universe-wide scan for OI anomalies with baseline and context. The scope ('across every Bybit USDT perp') and emphasis on 'spikes' differentiate it from single-symbol or raw OI tools, though it doesn't explicitly name alternatives or state exclusions.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the bar is lower, yet the description adds high-value context: the call costs 0.01 USDC via x402 and payment is settled in USDC on Solana or Base. It also discloses the underlying data venues (Bybit, OKX) and the metric set. It stops short of describing rate limits or failure/payment-rejection behavior.

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

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

Three tightly packed sentences with the payload/scope first, the sibling distinction second, and the cost last. No filler, and the most decision-relevant information (what you get, when to prefer it) 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?

An output schema exists, so return-shape explanation is unnecessary, and the description still summarizes contents plus payment and scope, which is sufficient for correct invocation. Minor gaps: no mention of rate limits, symbol casing expectations, or what happens on payment failure.

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 there is a single parameter, so the schema already documents 'symbol' with an example and the SOLUSDT default. The description's 'ANY USDT perp' phrasing broadens the symbol scope slightly, but adds no syntax, formatting, or casing guidance beyond what the schema provides.

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

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

States a specific verb+resource ('Open interest for ANY USDT perp') and enumerates exactly what is returned: Bybit OI in base units and USD with 1h/24h change, OKX open interest, and mark price. It also carves out sibling get_positioning by noting it 'covers SOL and BTC only', so an agent can discriminate without opening a 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?

Gives a clear routing rule against one sibling (get_positioning is SOL/BTC only, so this tool is for any USDT perp) and flags the paid nature of the call. It does not address other plausible alternatives such as get_oi_spike_scan or get_market_snapshot, so coverage is good but not exhaustive.

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

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

Annotations already establish readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely new behavioral context the annotations cannot express: a per-call cost of 0.01 USDC settled via x402 on Solana or Base, which tells the agent this is a paid call and what payment rail it uses. It stops short of describing rate limits or latency.

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

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

Two tightly packed sentences: the metric definition leads, the pricing disclosure follows. Every clause carries information and nothing is padded, though the first sentence is dense enough that a reader may need a second pass.

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?

An output schema exists, so return-value shape need not be explained, and both optional parameters are fully covered by the schema with defaults. The description supplies the metric definition and the payment cost, which are the two things structured fields cannot convey; only the relative-positioning guidance versus sibling tools is absent.

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

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

Schema coverage is 100%: both bps (window ±bps around mid, 5-500, default 50) and symbol (USDT perp, default SOLUSDT) are fully documented in the schema. The description's '±N bps of mid' restates the schema rather than adding format or boundary guidance, so baseline 3 applies.

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

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

Names a specific resource (orderbook imbalance) and scopes it precisely to USDT perps, then defines the metric itself: resting bid/ask liquidity in USD within ±N bps of mid plus the ratio and a skew read. This is clearly distinguishable from the neighboring get_orderbook_walls, which surfaces resting wall sizes rather than the imbalance ratio.

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 the metric is useful (gauging two-sided liquidity pressure within a mid window) but never states when to prefer it over get_orderbook_walls, get_spread_arb, or get_long_short. No prerequisites or exclusions are given; usage must be inferred from the metric definition.

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

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

Annotations already cover the safety profile with readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds important non-annotation behavior by stating the 0.01 USDC per-call cost and the x402 payment options on Solana or Base, though it omits rate limits, error handling, and pagination.

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

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

The description is two sentences, front-loaded with the tool's data content and followed by a compact cost note. There is no filler or repetition, and every sentence contributes to selecting or invoking the tool.

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

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

The tool is a simple read-only paid query with a fully documented schema and an output schema, so the description need not explain return fields. It covers what is returned and the payment requirement, but it stops short of usage routing against the sibling orderbook-imbalance tool.

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

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

Schema description coverage is 100%, so both parameters, top and symbol, are fully documented in the schema. The description adds only general scope, 'any USDT perp,' and does not provide format, defaults, or constraints beyond what the schema already states, 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 names a specific resource, orderbook walls for USDT perps, and defines them as the largest resting orders per side with USD size and distance from mid. That is more than a restatement of the name, but it does not explicitly differentiate this tool from the sibling get_orderbook_imbalance, so it stops short of a 5.

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

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

There is no when-to-use guidance, no named alternatives, and no exclusions. The only conditional information is the per-call price and payment chain, which is cost disclosure rather than usage guidance, leaving the agent to infer whether this or get_orderbook_imbalance 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?

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral details beyond annotations, including the 0.02 USDC per call cost, the x402 payment mechanism, and the 5-minute sampling cadence. These are important operational traits an agent needs to know.

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 core definition, then add sampling and cost details. Every sentence contributes useful information with little or no redundancy.

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

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

The description covers the metric, chain, asset class, statistical breakdown, sampling frequency, and cost. Given that an output schema exists and annotations describe safety, this is complete enough for an agent to select and invoke the tool 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?

Schema coverage is 100%, so the schema already documents symbol and hours fully. The description adds useful context about the metric and output stats, but it does not substantially clarify individual parameters beyond what the schema provides.

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

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

The description clearly identifies the resource (tokenized stock peg deviation on Solana) and the metric (DEX price vs underlying last trade in bps). It is specific enough to understand what the tool returns, though it does not explicitly differentiate itself from sibling tools like get_peg_sessions or get_peg_universe.

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 about when this tool could be relevant: measuring the peg deviation of tokenized US equities on Solana. However, it does not state when to prefer it over alternatives, mention exclusions, or provide selection criteria relative to similar tools.

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

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

Annotations already cover the safety profile (readOnly, openWorld, idempotent, non-destructive), so no caveats are needed there. The description adds important supplementary behavior: a 0.03 USDC per-call cost paid via x402 on Solana or Base, and the flagging of the worst off-hours window. No contradiction with annotations.

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

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

The description is compact and front-loaded: the core session breakdown appears first, followed by the control definition and pricing in a few short sentences. Every sentence adds distinct value with no filler or repetition.

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

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

With only two parameters, fully covered schema descriptions, and an output schema present, the description supplies the remaining essential context: session categories, metric types, the market-open control, and paid-call behavior. 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%: symbol and days are already documented with format, range, and default. The tool description adds no extra parameter-level meaning, 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 identifies the tool as providing tokenized-equity peg deviation statistics broken out by trading session (open, premarket, afterhours, overnight, weekend), with specific metrics enumerated. This distinguishes it from sibling tools like get_peg_deviation and get_peg_universe, even without naming 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?

It gives clear context for when to use this tool: when session-level peg deviation, off-hours comparison, and the worst off-hours window are needed, with market-open as the control. It does not explicitly name alternatives or state when not to use it, so it falls short of a 5 but is well beyond no guidance.

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

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

Annotations already establish this as read-only, idempotent, and non-destructive. The description adds meaningful context by disclosing the per-call cost (0.05 USDC via x402) and the important exclusion rule that dead pools are not reported as perfect pegs. These are behavioral details beyond what the annotations express.

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 with no filler: the core ranking and metric set is front-loaded, the dead-pool exclusion is a critical caveat, and the payment requirement is included. 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 read-only universe listing with zero required parameters, an output schema, and complete annotations, the description covers what the tool returns, how it is priced, and an edge-case behavior. Nothing essential for calling it correctly is missing.

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

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

Schema description coverage is 100%, with both parameters (days, min_liquidity_usd) already documented in the input schema. The description adds context around liquidity and lookback, but it does not need to compensate for any schema gap. 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 precisely what the tool does: it returns every tracked tokenized US equity ranked by off-hours peg risk, with specific metrics (p95/max deviation bps, market-open control, median liquidity). This is a specific resource and operation, clearly distinct in scope from single-asset sibling tools like get_peg_deviation.

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 usage context is implied by the title and first sentence: use this when you want a broad universe-level ranking of tokenized stocks by off-hours peg risk. However, there is no explicit guidance about when not to use it or which sibling alternative to prefer, such as get_peg_deviation for a specific asset.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds valuable non-obvious behavioral context: the per-call fee of 0.001 USDC paid via x402, the cross-venue data sources, and the use of proprietary tape data for liquidations.

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 earning its place: when to use, what data is returned, and the cost/fee mechanism. The most important usage guidance is front-loaded, 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?

Given the single optional parameter and the presence of an output schema, the description is complete. It names the key data fields, cost, venues, and data provenance, so 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 description coverage is 100%, as the symbol parameter is fully documented with examples and default value. The tool description itself adds no extra parameter semantics, so the baseline score of 3 applies.

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

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

The description clearly states the tool's purpose: retrieving one perp market in a single call, and enumerates the specific data returned (funding, open interest, long/short ratio, liquidations). This distinguishes it from narrow siblings like get_funding_cross or get_open_interest, even without naming 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?

The opening phrase 'Use when an agent needs one perp market in a single call' gives a clear usage context. It does not explicitly mention when not to use it or name alternative tools, but the context is specific 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?

Annotations already establish readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral context beyond this: the exact data mix, the 1h/24h change windows, the Bybit venue, and a transparent cost of 0.004 USDC per call via x402 on Solana or Base. This is useful operational information an agent needs before invoking.

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. The core data and venue are front-loaded, and the cost/payment detail is added as a final, clearly separable clause. 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?

For a zero-parameter read-only tool with an output schema, this description is complete. It names the assets, metrics, timeframes, venue, and cost. Since the output schema exists, the description does not need to explain return values, and no additional selection criteria or prerequisites are required to invoke it.

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

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

The tool has zero parameters, so there is no parameter semantics for the description to clarify. The baseline of 4 applies because no parameter documentation burden exists; the description instead focuses on what data is returned and at what cost.

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 is specific about what the tool returns: SOL and BTC long/short account ratio and open interest with 1h/24h changes on Bybit. It does not use an explicit verb like 'retrieves' or 'returns', but the resource, venue, and metrics are unambiguous. It is distinguishable from siblings like get_open_interest and get_long_short mostly by its combined scope, though it does not explicitly call out those alternatives.

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. Sibling tools such as get_long_short, get_open_interest, get_oi_spike_scan, and get_funding_rate cover overlapping concepts, and the description does not state when positioning is preferable or how it differs. Usage is only implied by the tool name and title.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds valuable context beyond annotations: the real-time nature ('right now'), the specific fee levels returned, and the cost of 0.005 USDC per call via x402. This is meaningful behavioral and operational 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?

Three short sentences, each earning its place: the core output, the intended use case, and the cost. The most important information is front-loaded, and there is no fluff or repetition of schema/annotation data.

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

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

For a zero-parameter, read-only tool with an output schema and rich annotations, the description is complete. It tells the agent what the tool returns, why to use it, and what it costs. 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?

The tool has zero parameters, and schema coverage is 100%, so the baseline is 4. The description adds no parameter-specific semantics because none are needed; it correctly focuses on the output and usage 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 identifies the resource (Solana priority fees) and what the tool provides: a fee estimate at every level from min to unsafeMax in micro-lamports per compute unit, plus a recommended tip. It does not explicitly differentiate from the sibling get_jito_tips, which likely covers a related but distinct concept, so it stops short of a 5.

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

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

The phrase 'For bots that need their transactions to land' gives a clear use case and implies this is for transaction inclusion. It does not explicitly state when not to use it or name alternatives, but the context is sufficient for an agent to infer appropriate usage.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds important behavioral context beyond annotations: the call costs 0.003 USDC via x402 on Solana or Base, and the data is described as a 'complete unthrottled tape' covering all recorded USDT perps. This is genuinely useful operational information.

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

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

Three tight sentences, each earning its place: data sources and output fields, full perp coverage, and cost/payment rail. No filler or redundancy; the most important distinguishing detail—complete unthrottled tape across venues—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?

With an output schema present, annotations covering the safety profile, and all parameters documented in the input schema, the description is complete enough. It adds the critical missing operational detail (cost and payment method) and clearly states the tool's scope relative to the broader tool family.

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 four parameters with 100% coverage, so the description does not need to add much. It reinforces the 'not just majors' concept that maps to the scope and symbol parameters, but it does not add meaningful detail beyond the schema's own descriptions.

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

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

The description names a specific resource—recent perp liquidations across Bybit, OKX, and Binance—and specifies the exact fields returned. It also differentiates itself from sibling liquidation tools by emphasizing the 'complete unthrottled tape' and coverage of 'any USDT perp, not just 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?

The description gives clear context for when this tool is appropriate: when the user needs a full, unthrottled recent liquidation tape across multiple venues, including non-major perps. It does not explicitly name alternatives or state when not to use it, but the scope is clear 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?

Annotations already declare this a read-only, idempotent, non-destructive operation. The description adds meaningful behavioral context beyond that: each call costs 0.005 USDC and requires x402 payment using USDC on Solana or Base. This is useful cost and payment-rail information not captured by the annotations.

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

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

The description is two short, front-loaded sentences. The first defines the returned data and the second discloses the cost and payment rail, so every sentence adds value without 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 no-parameter, read-only health endpoint, the description is complete. It names the returned metrics, states the cost/payment expectation, and the annotations and output schema cover safety and return formatting.

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

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

The tool has zero parameters and the schema coverage is 100%, so no parameter semantics are needed. The baseline for a parameterless tool applies, and the description appropriately does not invent unnecessary parameter 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 names a specific resource (Solana network health) and enumerates the exact data an agent will receive: average TPS, current slot, current epoch, and epoch progress. This clearly distinguishes it from the many pricing, liquidation, and balance siblings in the tool list.

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

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

The purpose 'Solana network health' implies when to use it, and the cost note gives a practical consideration, but there is no explicit guidance about when to prefer this tool over alternatives or when not to use it. Usage context is implied rather than stated.

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

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

Beyond the read-only/idempotent annotations, the description discloses the multi-source fallback chain, when confidence/publish_time will be null, and the per-call cost of 0.001 USDC. This is rich behavioral context that materially informs invocation decisions.

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 key purpose is front-loaded, and every clause adds either source behavior, field semantics, or cost 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, read-only price feed with an output schema present, the description covers the essential operational details: sources, fallback, nullable fields, and cost. Nothing critical is missing for an agent 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?

The tool has zero parameters, so the baseline is 4; there is no parameter surface for the description to clarify. The description still adds useful context about pricing and source behavior, though no parameter-specific semantics are needed.

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

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

The description clearly states a specific verb ('get'), resource ('SOL/USD spot price'), and scope ('multi-source: Coinbase, Kraken, Pyth Hermes fallback'). It distinguishes itself from sibling price tools like get_btc_price and get_eth_price by asset, and from generic get_spot/pricing tools by naming the exact instrument.

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 is the tool for a live SOL/USD spot price, with source and fallback behavior and a cost. It does not explicitly name alternatives or exclusions, so it stops short of a 5, but an agent can infer when to use it.

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

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

Beyond the readOnlyHint=true and idempotentHint=true annotations, the description reveals the fallback order (Coinbase, Kraken, Pyth Hermes), the fact that the serving venue is returned, that Pyth confidence is provided when applicable, and the cost (0.001 USDC per call). No contradiction exists; the description enriches the agent's understanding of side effects and 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?

Three sentences with zero fluff. The primary use case is front-loaded, followed by return details, fallback mechanism, supported assets, and cost—all in a logical, compact flow. 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?

Given the single parameter with full schema coverage, the presence of an output schema, and annotations covering safety, the description is complete. It tells the agent when to use it, what it returns, the cost, and edge cases (declined for unsupported symbols). No additional information is needed 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?

The schema description for 'symbol' already covers the accepted values (SOL, BTC, ETH) and the default. Since schema coverage is 100%, the description adds no additional parameter-level detail. The baseline for full coverage is 3; there is no extra value to push it higher.

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 ('returns a spot price'), a clear resource (spot price), and explicitly notes it avoids venue selection. It names the assets served (SOL, BTC, ETH) and contrasts with alternatives (get_sol_price, get_btc_price) by emphasizing the 'without choosing a venue' scope. This clearly distinguishes it from its siblings.

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

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

The opening phrase 'Use when an agent needs a spot price without choosing a venue' provides clear guidance on when to invoke this tool. It implicitly suggests that when a specific venue is preferred, other tools should be used, but it does not explicitly name alternative tools. The cost disclosure and supported-asset list add useful context for decision-making.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower; the description goes beyond them by disclosing a concrete payment requirement: 0.02 USDC per call via x402 on Solana or Base. It does not mention rate limits or latency, but the paid-call detail is meaningful operational context.

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

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

One sentence, front-loaded with what the tool returns (best bid/ask per venue plus edge in bps) and ending with the cost. Efficient and well-ordered, with only slight run-on density in the venue list.

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

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

With an output schema present, return values need no explanation, and the description covers scope, venues, metric, and payment. Handling of the default symbol and the fee/pre-fee caveat is adequate for a one-parameter read tool.

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

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

Schema coverage is 100% and the single optional symbol parameter already documents its format and default, so the schema does the heavy lifting. The description adds only the constraint that the symbol is a USDT perp, which the schema already states, so baseline 3 applies.

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

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

The description states a specific resource and scope: cross-exchange spread and arbitrage edge for USDT perps, naming the three venues (Bybit, OKX, Hyperliquid) and the bps edge metric. It is clearly distinguishable from most siblings, though it does not explicitly contrast with near-neighbors like get_basis or get_funding_cross.

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 implies when the tool is useful (finding cross-venue arb edge) and discloses the per-call cost, but gives no explicit when-to-use/when-not or pointers to the adjacent spread/basis tools it overlaps with. The agent must infer the scenario.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, yet the description adds meaningful non-obvious context: a paid x402 call at 0.1 USDC on Solana or Base. That cost/auth detail is exactly the kind of behavior annotations cannot convey. It stops short of noting rate limits or what happens on unsupported symbols.

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: what the score is, what it composites, and what it costs. No redundancy, and the core definition is front-loaded before the pricing note.

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

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

With an output schema present, return values need not be explained. The description supplies the score range, the composite inputs, the use-case framing, and the payment terms, leaving no material gap for invoking 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 description coverage is 100% and the sole optional symbol parameter is documented in the schema with an example and default. The description adds only 'any USDT perp' as scope, so baseline 3 is appropriate.

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

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

States a specific resource (short squeeze score / long flush score, 0-100) and scope (any USDT perp), and names the exact inputs feeding the composite. An agent can distinguish it from single-metric siblings like get_funding_rate or get_long_short because it declares itself a composite derived from those signals.

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

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

The line 'One number for whether a trade is crowded and about to hurt someone' implies the decision context, but there is no explicit when-to-use vs when-not, and no routing to or away from siblings such as get_positioning despite overlapping signal. Usage is inferable but not spelled out.

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

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

Beyond the readOnly/idempotent annotations, the description discloses important non-obvious behavior: the call costs 0.01 USDC and is paid via x402 on Solana or Base. It also explains the analytical significance of the data, giving the agent a clear model of what this call does beyond its safety profile.

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

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

Two sentences convey the data content, timeframes, analytical purpose, and pricing with no filler. The core output is front-loaded, and the cost detail is appended as a separate practical note.

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 tool with an output schema and full annotation coverage, the description is complete. It states the metric, the deltas, the top-stables breakdown, and the payment requirement, leaving no essential decision information 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?

There are no parameters, so there is nothing for the description to clarify. The baseline for a zero-parameter tool applies, and the description appropriately focuses on outputs and cost 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 clearly identifies the resource (stablecoin supply and flows) and the specific outputs: total stablecoin market cap, 7d and 30d deltas, and top stables by size. This distinguishes it from the many sibling market-data tools, none of which target stablecoin aggregates directly.

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

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

The description provides clear context for when to use the tool, framing it as 'the macro risk-on / risk-off dial for crypto.' It does not explicitly name alternatives or exclusion conditions, but with zero parameters and a unique focus among siblings, the intended use case is evident.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds material non-obvious context: the cost of 0.02 USDC per call and the x402 payment mechanism on Solana or Base. It also clarifies the output granularity, going beyond what the annotations convey.

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

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

Two sentences deliver the resource, output details, comparison to a sibling tool, and pricing with zero filler. Key information is front-loaded and every sentence earns its place.

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

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

With only one fully documented parameter, an output schema present, and annotations covering safety, the main operational detail an agent needs is cost, which is included. The tool is also situated relative to get_token_risk, leaving no material gap for a calling agent.

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

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

The input schema already fully describes the single 'mint' parameter as an SPL token mint address in base58. The description repeats the Solana/SPL context but does not add new format, validation, or example details, 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 the resource (SPL token mint), the operation (retrieve top holders), and the specific outputs (per-account share and top-1/5/10 concentration). It also distinguishes the tool from get_token_risk, so an agent can tell them apart.

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 'A deeper cut than the summary in /api/token-risk' gives an explicit comparative signal that this tool is the more granular option for holder concentration. It does not enumerate exhaustive when-not-to-use conditions or other sibling alternatives, but the context is clear enough for routing a concentration-focused request.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable non-obvious context: the per-call cost of 0.005 USDC, the x402 payment mechanism, and the Helius DAS backend. This exceeds what the annotations alone provide without contradicting them.

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

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

Two terse sentences: the first front-loads what the tool returns, and the second states the cost and payment rails. Every clause earns its place with no filler.

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

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

With one fully documented required parameter, rich safety annotations, and an output schema, the description only needed to add non-obvious constraints like cost, which it does. An agent has everything it needs to invoke 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?

The schema fully documents the single `mint` parameter as an SPL token mint address in base58, so the description does not need to compensate. The description adds no new parameter-level meaning beyond what the 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 identifies the exact resource (SPL token metadata) and lists the returned fields (name, symbol, decimals, supply, price), so an agent can tell what it provides. It is not phrased as a full verb sentence, but it is specific enough to distinguish it from siblings like get_token_holders or get_token_risk.

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

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

The description implies the tool should be used when SPL token metadata is needed, and the cost disclosure is a relevant usage constraint. However, it does not explicitly say when to prefer this over related token tools or mention any alternative.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the per-call cost, the x402 payment mechanism, and the accepted networks (Solana or Base). It also clarifies the scope of what the tool does and does not check, which helps set expectations.

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 with no filler. The core purpose is front-loaded, the exclusion is stated clearly, and the cost/payment detail is placed last where it is easy to scan. 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 read-only tool with a full output schema and rich annotations, the description is complete. It covers what the tool returns, what it does not cover, the cost, and the payment network. An agent has everything needed to decide whether to invoke it and what input to provide.

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%: the only parameter, mint, is already documented as an SPL token mint address in base58. The description reinforces that the tool operates on SPL tokens but adds no new parameter-level detail beyond what the schema provides, 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 identifies the tool as an SPL token rug-risk checker and enumerates the specific signals it returns: mint/freeze authority status, top-1/top-10 holder concentration, and risk flags. It also explicitly distinguishes itself from honeypot/LP-lock checkers, making its purpose and scope unambiguous relative to siblings like get_token_holders and get_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 gives clear context: use this when you need rug-risk signals for an SPL token, and it explicitly says what it is not (a honeypot/LP-lock checker). It also surfaces the 0.01 USDC cost, which is important for deciding whether to call it. However, it does not name an alternative tool to use when honeypot/LP-lock checking is needed, stopping short of full when-not/alternative guidance.

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

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable non-obvious behavior: the 0.01 USDC per-call fee, x402/USDC payment rails on Solana or Base, and the Bybit USDT perp scope with funding rates. No contradiction with annotations.

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

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

Three short sentences, each earning its place: the result set, the screener label, and the cost/payment method. The most decision-relevant 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?

Given an output schema, 100% parameter schema coverage, and strong annotations, the description adds the missing contextual pieces: time window, universe, liquidity floor, funding rate attachment, and cost. Nothing needed to invoke it correctly is absent.

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 baseline is 3. The description's 'liquidity floor' echoes min_turnover_usd and 'top gainers and losers' maps to limit, but it adds no parameter details beyond what the 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 exactly what the tool returns: top gainers and losers over 24h across Bybit USDT perps above a liquidity floor, with funding rates attached. The 'what moved' screener label makes its role distinct among the many market data siblings, even without naming 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 description gives a clear use case ('what moved' screener) and specifies the universe and cost model, so an agent knows when to reach for it. It does not explicitly enumerate when not to use it or name alternative screeners, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the tool costs 0.01 USDC per call and specifies the payment rail (x402, USDC on Solana or Base), which is important for an agent deciding whether to invoke it.

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

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

The description is two tight sentences. The first front-loads the core value proposition and contents; the second adds the cost and payment detail. 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?

With no parameters, annotations covering safety, and an output schema present, the description covers everything an agent needs: what data is included, the pre-trade use case, and the cost. 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?

The tool has zero parameters and 100% schema description coverage, so there is no parameter documentation burden. The baseline of 4 applies, and the description appropriately focuses on what the call returns rather than inputs.

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

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

The description clearly states the tool's function: returning a comprehensive market snapshot in a single call, and enumerates the included data types (SOL+BTC prices, funding, Fear & Greed, positioning, open interest, liquidations). This differentiates it from the many sibling tools that each cover only one of these data points.

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 emphasizes 'one call,' which implies using it when a broad market overview is needed rather than calling multiple individual data tools. It does not explicitly name alternatives or state when not to use it, but the context is clear enough.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive. The description adds valuable context: data source (DefiLlama), aggregation method (protocol family across deployments, TVL-weighted change), and cost (0.005 USDC via x402 on Solana or Base). This goes beyond annotations and informs the agent of external dependencies and fees.

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, front-loaded with the core functionality, then adds data source and cost. It is concise and each sentence earns its place. Slightly verbose due to the cost details, but still efficient.

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

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

For a single-optional-parameter tool with an output schema and comprehensive annotations, the description covers the essential functional aspects (purpose, source, aggregation, cost). It does not describe error handling or response format, but the output schema presumably covers the latter. It is adequately complete for an agent to invoke correctly.

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

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

Schema description coverage is 100% and the schema itself explains the target parameter with examples and the omit behavior. The description adds only a minor clarification ('or a top-15 chains ranking') which is already implied by the schema's 'omit for top chains'. No significant added meaning beyond the schema.

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

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

The description clearly states the tool's function: retrieve TVL for a specific DeFi protocol with 1d and 7d changes, or a top-15 chains ranking. This is a specific verb+resource that distinguishes it from the many get_* siblings, none of which are TVL-related.

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 it (for TVL queries) and explicitly mentions the alternative of omitting the target for chains ranking. However, it does not name specific sibling tools or provide explicit exclusions. The context is clear enough for an agent to select it over other get_* tools.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context beyond annotations: it costs 0.02 USDC per call and specifies the payment rail (x402, USDC on Solana or Base). This is valuable operational information an agent needs before invoking the tool.

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

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

The description is compact and front-loaded with the core purpose in the first sentence. The second sentence 'Which venue is flushing whom' is evocative and short, helping convey intent without bloating. The cost note is essential. No redundant or wasted prose beyond minor stylistic flair.