LiquidVision — Crypto Derivatives Data

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses quota limits (Pro: 3, Bot: 20 subscriptions), the auth requirement (Pro or Bot key), and the one-time secret return with the exact HMAC verification header. These are non-obvious traits an agent could not infer otherwise.

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

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

Dense but front-loaded, leading with the tool's core action before enumerating alert types. Every clause carries information (thresholds, timing, defaults), though the type enumeration is lengthy.

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 mutation tool with no annotations and no output schema, it covers auth, quotas, subscription limits, and the return secret/verification flow. Minor gaps include the url format beyond 'HTTPS' and the role of api_key, but nothing critical to correct invocation 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 0%, so the description must compensate, and it does: it explains the semantics of type values (cascade, hl_near_liq, cluster_sweep) and the meaning of min_usd, x_normal, max_dist_pct, and symbol. Only url and api_key lack added meaning, but those are largely self-evident.

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: subscribing an HTTPS URL to push alerts rather than polling. It clearly differentiates itself from sibling tools like list_alerts and delete_alert, which are the read/remove counterparts.

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 'instead of polling' framing gives clear context for why an agent would choose this over repeatedly polling market data, and each type's trigger condition is spelled out. It stops short of explicitly naming alternative tools or stating when not to use it, but the usage context is unambiguous.

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

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

With no annotations, the description carries the full burden and does so: destructive and irreversible, deliveries stop immediately, the signing secret is discarded, cross-key deletes return {"deleted": false} and change nothing, and a Pro/Bot key is required. This far exceeds what annotations would typically cover.

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

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

Dense and front-loaded: the destructive warning and ownership rule precede the parameter and auth notes. Every sentence adds a distinct fact (reversibility, side effects, error case, auth tier) 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?

For a destructive mutation tool with no annotations and no output schema, the description supplies everything needed: irreversibility, side effects, auth requirements, id provenance, and the failure return shape. Nothing an agent needs to call it safely 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 coverage is 0%, so the description must compensate, and it documents both params: id is 'the number returned by create_alert or list_alerts' and api_key is explained as the X-API-Key header of the MCP connection or the api_key field. No parameter is left ambiguous.

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

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

States a specific verb+resource (permanently delete one webhook alert subscription) with explicit singular scope. It distinguishes itself from create_alert and list_alerts, which it names directly, so an agent can route to it without opening another 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?

Clear context is given: it deletes a subscription and points to create_alert as the way to re-obtain a signing secret. The ownership constraint ('only a subscription owned by the caller's API key can be deleted') is a strong use condition, though it stops short of an explicit 'use X instead when' exclusion.

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

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

With no annotations, the description carries the behavioral disclosure burden; it discloses that results are computed from live derivatives data across 13 venues and that the response includes liquidation cascades, funding extremes, positioning, and next risk zone. This conveys the tool's analytical behavior, though it does not discuss limits or non-determinism.

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

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

The description is one dense sentence with no filler; the capability label is front-loaded and the parenthetical output details justify their length. Every clause adds information an agent can act on.

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

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

For a two-parameter tool with no annotations and no output schema, the description conveys purpose, input style, output substance, and data provenance in one sentence. The omission of the symbol parameter and any response-format details prevents a perfect score.

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

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

Schema descriptions are absent (0% coverage), so the description must clarify the parameters. It meaningfully illustrates the 'question' parameter via a natural-language example, but it never mentions the optional 'symbol' parameter, its default, or what values it accepts.

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 capability: it answers natural-language questions like 'Why did BTC drop 4%?' with a grounded market explanation. This clearly distinguishes it from the sibling get_* data-retrieval tools, since it synthesizes an answer rather than returning a metric series.

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 example 'Why did BTC drop 4%?' and 'AI risk-intelligence answer' establish when to use the tool: when an agent needs an interpreted explanation rather than raw data. It does not explicitly name sibling tools or state when not to use it, 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?

No annotations are provided, so the description carries the full burden. It discloses key behavioral aspects: the audit is public, samples every 10 minutes, and includes metrics like diff %, snapshot age, and 24h mean/max. It also implies a read-only nature and warns about trust implications, though it does not explicitly state side-effect-free 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?

The description is reasonably concise and front-loaded with the core purpose ('public accuracy audit'). Each sentence adds value, though the final warning is more advisory than informational. Slightly longer than strictly necessary but well organized.

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

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

With no output schema, the description must summarize return values, and it does: diff %, snapshot age, 24h mean/max, and liquidation map scoring. It does not detail the exact response structure, but for a no-parameter, read-only audit tool, this is adequate for an agent to know what data it will receive.

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; the schema is emptyholonomic. With no parameters to document, the description already provides sufficient information about what the tool returns. 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?

The description clearly states the tool's function: it provides a public accuracy audit comparing open interest and funding against external exchange endpoints, and also scores the modeled liquidation map. This is specific and distinguishes it from sibling tools that report raw data (e.g., get_open_interest, get_funding_rates) rather than data quality metrics.

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

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

The description explicitly advises 'Read this before trusting any number here with money,' which tells the agent when to use this tool: when evaluating the reliability of other data. It does not name alternatives, but there are no sibling accuracy tools, so the usage 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?

No annotations, so the description carries the full burden and does so well: it discloses the new-email-only constraint, that existing keys are never returned, where the owner can find the key, the downstream use (X-API-Key, 300 req/min vs. anonymous budget), and the upgrade path. It stops short of stating explicitly that a new account/credential is created as a side effect.

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?

Five dense sentences, all front-loaded and purposeful; the new-email constraint and the 'ask the user first' instruction are prominent. Slightly long but every clause adds operative 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 single-param credential tool with no output schema, the description covers scope, limitations, key usage, and the acquisition precondition. Nothing needed to call 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?

With 0% schema coverage the description must carry the single parameter, and it does: the email is the owner's real email, must be asked for from the user, and must not be invented. Meaningful semantics added beyond the bare 'email' string type.

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 ('Get a free LiquidVision API key') and immediately scopes it to a distinct operation vs. the all-market-data sibling set. An agent can tell this is an auth/credential tool, not a market query, 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?

Gives clear conditions: only works for a NEW email, existing account keys are never returned, and instructs the agent to ask the user for the email first and not invent one. No explicit sibling routing is needed since siblings are unrelated market tools, so this is strong but not full when/when-not/alternatives coverage.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It describes the data coverage (open interest, funding, liquidations) but does not mention operational aspects such as data freshness, potential latency, or whether it aggregates live data. For a read-only 'get' tool, the side effects are minimal, but the description does not explicitly confirm it is read-only or disclose any limitations. This is adequate but not comprehensive.

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

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

The description is concise and front-loaded with the core concept 'Arbitrum perps board'. It then enumerates the key metrics in a compact list and ends with a practical usage hint. It avoids redundancy and stays within two sentences, making it efficient while still informative.

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

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

Given the tool has no parameters and no output schema, the description needs to convey what the agent will receive. It does that by listing the included metrics (open interest, funding, liquidations) and the comparison against CEXs. It does not specify the exact response format (e.g., list of coins), but for a board-style tool this is likely evident from the metrics. The description is sufficiently complete for an agent to decide whether to call 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 the schema provides no parameter documentation. Per the baseline, with 0 params the score is 4. The description does not need to add parameter details, and it doesn't attempt to. It focuses on the content of the board, which is appropriate.

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

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

The description clearly states it is an 'Arbitrum perps board' covering GMX v2 open interest per coin, funding, and liquidations. The verb 'get' plus the specific resource (Arbitrum perps board) makes the purpose clear. It does not explicitly contrast with sibling tools like get_funding_rates or get_liquidations, but the composite nature and the focus on Arbitrum vs CEXs differentiates it enough for an agent to infer its 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 provides a clear usage scenario: 'Ask this for how is Arbitrum positioned vs CEXs'. This is explicit guidance on when to invoke the tool. It does not list exclusions or alternatives, but the use case is sufficient for an agent to decide between this and more specialized tools like get_funding_rates or get_liquidations.

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

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

No annotations are provided, so the description carries the full burden. It does disclose a key interpretation detail—'Positive = money flowing in'—which adds useful behavioral context. However, it does not mention data source, aggregation method, or whether any filtering is applied, though for a read-only data tool this is a reasonable disclosure level.

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

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

Two short sentences with zero filler. The first sentence front-loads the metric and its dimensions, the second adds a clarifying semantic note. Every word earns its place.

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

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

Given zero parameters and no output schema, the description sufficiently conveys the data's dimensions and sign interpretation. It does not specify the exact return shape (e.g., rows grouped by exchange and symbol), but for a simple data retrieval tool this is nearly complete.

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

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

The tool has zero parameters, and schema description coverage is 100% vacuously. Per the baseline for no-parameter tools, a 4 is appropriate. The description adds context about the fixed windows (1h/4h/24h) but 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 identifies a specific resource—'Derivatives cash flow per exchange'—and elaborates with precise dimensions: 'net USD into/out of open interest over 1h/4h/24h windows, per core symbol.' It clearly distinguishes this from sibling tools like get_open_interest (which reports levels, not flows) and get_cvd, 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 gives no guidance on when to use this tool versus alternatives. It does not mention what question it answers, when to prefer a sibling, or any exclusions. The agent is left to infer the use case from the metric description alone.

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

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

With no annotations provided, the description carries the full burden and does add substantive behavior: it defines the size buckets and interprets divergence. It does not disclose the exact delta computation or windowing behavior, but the provided definitions and signal interpretation go meaningfully beyond the bare tool name.

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

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

Two tight sentences with no filler. The core metric and thresholds are front-loaded, and the signal interpretation is a single clause at the end.

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

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

The metric and its segmentation are well explained, but with no output schema and no parameter guidance, the return format and the effect of the minutes parameter remain unstated. It works as an overview but not as complete call-time guidance.

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

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

Schema description coverage is 0% and the description does not mention symbol or minutes at all. The agent must infer their meaning from names and defaults; the size-bucket definitions do not clarify what time window 'minutes' controls or accepted symbol formats.

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 metric (cumulative volume delta) and its segmentation by trade size with exact thresholds (retail <$10K, mid <$100K, large <$1M, whale >$1M). It also adds an interpretive signal (whale-vs-retail divergence = smart-money signal), which clearly distinguishes it from sibling analytics 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 a use case by framing whale-vs-retail divergence as a smart-money signal, but it never states when to prefer get_cvd over siblings such as get_microstructure or get_footprint, nor does it give explicit exclusions or alternatives.

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

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

No annotations are provided, so the description carries the burden. It discloses valuable behavioral context: the data comes from archived trade streams of Binance, Bybit, OKX, Bitget and Gate, and describes the returned structure (30 price levels). However, it says nothing about permissions, rate limits, pagination, or freshness of the archive, leaving gaps for a no-annotation 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?

Front-loaded with the resource and its payload, followed by usage routing and parameter constraints. It is dense and runs as one paragraph, but essentially 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?

Given no output schema and no annotations, the description does the work of explaining return content (taker buy/sell volume and trade count per price level) and all parameter ranges. It is nearly complete, with only operational details like rate limits or upstream latency left unstated.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: symbol is constrained to BTCUSDT/ETHUSDT/SOLUSDT only, minutes is the look-back window bounded 15-10080, and step is the candle size in minutes bounded 1-240. This fully documents all three otherwise-bare parameters.

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

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

States a specific resource (footprint chart data) and details exactly what each candle contains: taker BUY/SELL volume in USD plus trade count at each of 30 price levels. It explicitly distinguishes itself from get_cvd for net flow by trade size, so an agent can route correctly 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?

Names the intended use ('see at which prices aggressive buyers or sellers were absorbed') and names the alternative tool get_cvd with the condition that selects it ('for the net flow over time by trade size'). Clear when-to-use and sibling routing.

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

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

With no annotations, the description carries the full burden and does well: it explains median-over-window behavior, annualization per settlement cycle, and why the latest print is avoided. It doesn't cover rate limits or data availability, but the core computational behavior is transparent.

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

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

Two tight paragraphs with the core concept front-loaded and every clause adding methodological detail. No filler, no repetition of the tool name or schema fields.

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

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

For a tool with no output schema, the prose describes the per-coin outputs (spread, long venue, short venue), annualization, and ranking window. It falls slightly short by not stating how `limit` or `min_venues` affect the returned list, but the essential behavior is covered.

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

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

The description adds meaningful semantics to `window` by tying it to the median calculation and noise rationale. However, `limit` and `min_venues` are left completely unexplained despite 0% schema description coverage, so two of three parameters rely only on their names and defaults.

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

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

The first sentence names the exact resource and metric: coins ranked by how far funding disagrees across exchanges. The level of specificity — spread in APR points, venue to hold long/short — clearly differentiates it from sibling funding tools even without naming them.

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

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

No explicit 'use this when' or 'use X instead' guidance appears. The intended use is implied by the definition, but there are no exclusions or comparisons to similar funding-related tools like get_funding_rates or get_funding_history.

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

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

With no annotations, the description carries the full burden and does well: it discloses that this is the LIVE predicted rate sampled over time (not settled payments), the row grain (one row per venue per time bucket), unit semantics (fraction per settlement interval), and the funding_hours interval values (1, 4, 8). It omits auth, rate limits, and pagination behavior, which keeps 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?

Front-loads the output shape, then annualization guidance, then the routing rule to the alternative tool. Dense but every sentence serves a purpose; the run-on formatting is slightly harder to scan than a clean bulleted 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?

An output schema exists so return values needn't be restated, yet the description's column-level detail is genuinely additive for interpreting funding_rate. For a two-parameter read tool with no annotations, this is nearly complete; only operational details like limits or pagination are 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 0%, so the description must compensate, and it does: it documents the symbol format ('BASEUSDT') and the range for minutes ('5 to 20160'). It never explicitly says minutes is the lookback window, but the time-bucket framing makes the intent inferable.

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 and the exact output shape: 'Funding rate over time for one contract, one row per venue per time bucket'. It also explicitly contrasts itself with the sibling get_funding_settlements, so an agent can distinguish the two without opening either 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?

Names the alternative tool get_funding_settlements and the condition that selects it ('for the rates actually paid at each settlement'), and clarifies this tool returns the live predicted rate sampled over time. It gives clear context but does not mention other nearby siblings such as get_funding_rates or get_funding_dispersion, so no full exclusion set.

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

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

With no annotations, the description carries the full burden. It discloses the sign convention ('Positive rate = longs pay shorts'), which is a non-obvious behavioral detail, and clarifies the scope ('every tracked exchange/symbol pair'). It does not mention any limitations like rate limits or pagination, but given it is a simple read-only tool with no parameters, the disclosed behavior is adequate.

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

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

The description is two sentences with no fluff. The primary purpose is stated first, and the second sentence adds a valuable clarification about the sign meaning. It is front-loaded and every word earns its place.

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

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

For a parameterless tool with an output schema, the description is complete. It states what data is returned and the scope, while the output schema presumably defines the response structure. Nothing needed to invoke the tool 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?

The tool has zero parameters, and the input schema is empty. The baseline for 0-parameter tools is 4, and the description adds no parameter details because there are none to document. It correctly focuses on output semantics instead.

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

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

The description clearly states the tool retrieves latest perpetual funding rates and mark prices for every tracked exchange/symbol pair. The verb 'get' and resource are specific, and the 'latest' qualifier distinguishes it from historical tools like get_funding_history and get_funding_dispersion, 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 description provides no guidance on when to use this tool versus alternatives such as get_funding_history for historical data or get_funding_dispersion for distribution analysis. It simply describes what it returns, leaving the agent to infer its appropriate context.

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

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

No annotations are provided, so the description carries the burden. It discloses the data source (Binance and Bybit), the row granularity (one per settlement), the lookback limit (730 days), and the distinction from live data. However, it doesn't mention pagination, rate limits, or what happens when no data exists for a symbol. The description adds useful behavioral context but not exhaustive.

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

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

Two sentences with no waste. The core purpose is front-loaded, and the sibling distinction is placed at the end. Every sentence earns its place.

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

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

For a simple 3-parameter tool with no output schema, the description covers the main purpose, data source, time range, and sibling distinction. It doesn't explain return format or exchange parameter values, but the tool is relatively simple. The description is complete enough for an agent to select and invoke it correctly in most cases.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'any pool coin (e.g. BTCUSDT)' which clarifies the symbol parameter, and 'up to 730 days' which bounds the days parameter. However, it doesn't explain the exchange parameter's possible values or the default behavior of 'all'. The description adds some meaning but leaves gaps.

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

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

The description clearly states the tool returns settled funding rates, one row per settlement, from Binance and Bybit history, up to 730 days for any pool coin. It also distinguishes itself from get_funding_history, which is the live 10-second archive since July 2026. This is a specific verb+resource with clear scope and sibling differentiation.

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

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

The description explicitly says this is the backtest series and names the alternative get_funding_history for live 10-second data. This gives an agent clear guidance on when to use this tool vs the sibling. It also implies usage for historical/backtest 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?

With no annotations, the description carries the full burden and does so well: it discloses the auth mechanism (X-API-Key header or api_key param), tier-gated history windows (free 24h, Pro 31-day, Bot full), and the 5000-row limit. It does not state rate limits or error behavior, keeping it below 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?

Dense and front-loaded: the dataset list and the CSV/backtest purpose lead, with auth and tier constraints after. Every clause carries information, though the run-on pipe-delimited dataset list is slightly awkward.

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

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

No output schema, but the description states the CSV return format, and it covers auth plus all tier/limit boundaries an agent needs. The only real gap is the undocumented symbol and exchange parameters.

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

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

Schema description coverage is 0% across 7 params, so the description must compensate. It explains dataset, start/end (ISO, UTC), limit (max 5000), and api_key, but leaves symbol and exchange completely undocumented in both schema and description.

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

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

States a specific verb+resource and output form ('Historical rows as CSV, for backtests') and enumerates the exact datasets served, which lets an agent pick it apart from siblings like get_funding_history or get_liquidations. It does not name a sibling to contrast against, so it falls 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?

Gives a clear primary use case (backtests), a within-tool alternative for bulk ('for bulk use download_url'), and an explicit row cap at which local retrieval stops being appropriate. It lacks an explicit when-not-to-use framing against the many get_*/history siblings.

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

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

With no annotations, the description carries the full burden and does well: it reveals the auth path (X-API-Key header or api_key param) and the plan-dependent history limits, which the agent cannot infer elsewhere. It omits error behavior (e.g., invalid address) and pagination of snapshots, 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?

Front-loaded with the account/address scope, then the returned fields, then the auth/history caveats. One dense sentence plus a second, with no filler, though the bracketed '[measured]' tag and the triple-tier history clause make it slightly heavy.

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 2-param tool with no annotations and no output schema, it covers the essentials: what is returned (live positions with detailed fields), where data comes from, and how auth/history depth works. Missing only edge-case/error behavior and snapshot pagination detail.

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

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

Schema coverage is 0%, so the description must compensate. It clarifies the api_key parameter's fallback to the connection's X-API-Key header, which is genuinely useful, but adds almost nothing about the required `address` format beyond 'by address'.

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 ('One Hyperliquid account by address') and enumerates exactly what is returned (positions, account value, archived snapshots). It is clearly distinguishable from siblings like get_hl_whales or get_hl_liquidation_map without opening any 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?

It discloses the history-depth tiers (24h free, 31 days Pro, full history on Bot), which implies when a paid key is needed, but it never names an alternative tool or states when NOT to use it versus related siblings. Usage is implied rather than instructed.

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

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

With no annotations, the description carries the burden and mostly succeeds: it discloses the data source (live from Hyperliquid), freshness (cached 2 minutes), the OI convention (one side), and that it takes no arguments. It lacks any statement on auth/rate limits, but for a public read endpoint that is a minor gap.

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 purpose and scope, then the return fields, then the sibling exclusion and caching note. Dense but every clause is informative; slightly telegraphic ('one side') but not padded.

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

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

No output schema exists, but the description enumerates the returned fields (markets as dex:COIN, open interest USD, 24h volume, mark price, hourly funding and APR), so an agent knows what to expect. Complete for a zero-argument 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?

The tool takes zero parameters, so the baseline is 4. The description reinforces this explicitly with 'No arguments,' which is more than the empty schema says.

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 (perp markets deployed by third parties on Hyperliquid) and gives concrete examples (xyz:SP500, xyz:GOLD). Explicitly distinguishes itself from siblings get_open_interest and get_funding_rates, which it says cover Hyperliquid's own crypto listing.

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?

Names the alternatives (get_open_interest, get_funding_rates) and the exact condition that selects this tool instead: HIP-3 builder dex markets such as equities, commodities and pre-IPO names. No inference required for routing.

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

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

With no annotations, the description carries the full burden and does well: it discloses the data is exchange-measured rather than modeled, and explicitly warns of partial coverage (large accounts only). It does not mention permissions, rate limits, or pagination, so it falls short of full 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?

Front-loaded with the core identity and the model/measurement distinction, then the coverage caveat, then range values. Dense but every clause carries information; minor awkwardness in fragment-style 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?

No output schema, so the description usefully enumerates the returned constructs (long/short notional per bin, cumulative curves, largest positions) and the coverage limitation. Missing only the meaning of 'symbol' and any guidance on the retentive range default beyond the schema default.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: it enumerates the valid 'range' values (12h | 1d | 3d | 7d | max) and adds a selection hint. 'symbol' is left unexplained, so compensation is incomplete for a 2-param tool.

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

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

States a specific verb+resource ('Liquidation map for Hyperliquid') and immediately scopes it as measured data ('not a model'), which distinguishes it from the sibling get_liquidation_map. It further specifies the exact content (leveraged positions of the 10,000 largest accounts binned by liquidation price, long/short notional, cumulative curves).

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?

Provides useful context ('Partial coverage: large accounts only', 'recommended: large accounts run low leverage') and lists valid ranges, but never states when to pick this over nearby siblings such as get_liquidation_heatmap, get_liquidations, or get_liquidation_cascades. Usage is implied rather than routed.

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

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

With no annotations, the description carries the burden and does reasonably well: '[measured]' signals real exchange-reported data rather than modeled, it discloses that sort defaults to distance ordering, and it flags snapshot staleness via age_s. It omits auth/permission requirements and any rate-limit or pagination 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?

Dense and front-loaded: population and ordering come first, then filters, then the cross-tool handoff and freshness note. Every clause earns its place, though the filter list is compressed into a single run-on sentence.

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

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

With no output schema, the description correctly fills the gap by describing row contents (account address, liquidation price, age_s) and the default ordering. The unexplained 'limit' parameter and absent auth/safety context are the only meaningful omissions for a six-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 0%, so the description must compensate, and it documents five of six parameters (coin, side, min_usd, max_dist_pct, sort) including the non-obvious 'sort=value' meaning. Only 'limit' is left undocumented, so the compensation is strong but incomplete.

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 verb+resource (leveraged positions of the 10,000 largest Hyperliquid accounts) and states the exact ordering semantics (closest to liquidation first, sort='value' = largest first). This is clearly distinguishable from siblings like get_hl_liquidation_map and get_top_traders.

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

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

Explains how to use the output: 'Each row carries the account address; pass it to get_hl_account,' which is an explicit follow-up route. It does not, however, state when to prefer this tool over related siblings such as get_liquidation_heatmap or get_top_traders.

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

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

With no annotations provided, the description carries the full behavioral burden. It transparently discloses that the tool aggregates raw data into discrete events and explains what each event contains, including the market_wide composite. However, it does not disclose pagination, result ordering, the meaning of the 'normal minute' baseline, or any rate/auth considerations. It discloses the core transformation but not operational details.

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

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

The description front-loads the core purpose in the first sentence, then uses a tight list to enumerate return fields, and closes with the market_wide special case. Every sentence earns its place and the layout is logical. Slightly verbose in the field enumeration, but well-organized for an agent to parse.

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

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

Because there is no output schema, the description correctly takes on the burden of explaining return values, and it does so thoroughly. However, the two parameters are completely undocumented in both schema and description, and with no annotations the operational context (limits, defaults, ordering) is left for the agent to guess. Reasonably complete on the output side, incomplete on the input side.

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

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

Schema description coverage is 0% and the description never mentions the 'hours' or 'limit' parameters at all. While their purpose (time range and result cap) is inferable from their names, the description provides zero guidance on semantics, valid ranges, or defaults beyond what the schema's default values show. With low coverage, the description was obligated to compensate and did not.

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

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

The description uses a specific verb-resource pair ('Liquidation cascades as discrete events') and explicitly contrasts with 'a raw feed,' which is a sibling tool (get_liquidations). It enumerates the exact fields returned (coin, side, duration, USD totals, price moves), making the tool's function unmistakable and distinguishing 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 phrase 'rather than a raw feed' implies the tool is the aggregated/event-level alternative to a raw liquidation feed, but it never names the sibling (get_liquidations) or states explicit conditions for when to choose this over the raw feed or the heatmap/map siblings. Usage context is implied, not explicit, and no exclusions are given.

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

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

No annotations, so the description carries the full burden, and it does disclose meaningful behavior: the output shape, the rule that a level disappears once price trades through it, and an explicit size warning (~35,000 numbers). It omits auth/prerequisite or rate-limit context, so not quite a 5, but it goes well beyond restating inputs.

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?

Information is front-loaded (what it is, how it differs, then size, then params), and most sentences earn their place. It is dense but not padded, though the internal-grid detail and the trailing param list make it slightly long; the '[modeled]' prefix adds nothing.

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

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

With no output schema and no annotations, the description must do everything, and it explains the return structure, the semantics of disappearing levels, and answer size, plus all parameter values. Nothing an agent needs to invoke or interpret it 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?

With 0% schema coverage the description fully compensates: it gives the symbol format (BASEUSDT) and enumerates allowed values for both optional params (exchange: all|binance|bybit|okx; range: 12h|1d|3d|7d) that the schema leaves as bare strings. This is exactly the information missing from the structured fields.

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

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

The description states precisely what the tool returns: a time-by-price-bin grid of estimated USD liquidation levels, with named fields (grid[t][b], cols[t], bins[b], price[t]). It explicitly distinguishes itself from the sibling get_liquidation_map ('current picture only'), so an agent can tell the two apart 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?

It names the alternative (get_liquidation_map) and the exact conditions that select each: use the sibling for the current picture, use this one 'to see when a cluster formed and whether it is still there.' Both the when and the when-not are explicit.

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

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

With no annotations, the description carries the full burden and does so well: it flags the output as '[modeled]' (estimated, not exact), cites a backtest statistic, and explicitly disclaims predictive power. It does not cover refresh latency or rate limits, but the safety/interpretation context is strong.

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

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

Dense but front-loaded: the core definition leads, then range, then the interpretive framing and disclaimer. Slightly run-on in the middle clause listing leverage tiers and exchanges, but no sentence is purely decorative.

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

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

With no output schema and no annotations, the description adequately covers the return shape (per-bin notional, leverage-tier and exchange splits, cumulative long/short curves) plus the caveat about modeled estimates. Only refresh cadence and pagination/limits are unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: range values (12h|1d|3d|7d), exchange options (binance/bybit/okx or 'all'), symbol example (BTCUSDT), and the leverage tiers exposed in the output. It doesn't explicitly tie each option list back to a named parameter, but the meaning is recoverable.

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 (liquidation map for a perp symbol) and precisely defines its shape: estimated notional of leveraged positions per price bin at liquidation price, split by leverage tier and exchange. The scope ('if price reaches this level, how much is there') is concrete enough to tell it apart from raw liquidations, cascades, or heatmap 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?

States the question it answers and explicitly routes live scoring to the sibling get_accuracy, giving the agent a clear primary use case. It stops short of naming when to prefer get_liquidation_heatmap or get_liquidations instead, so alternative selection is left partly to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses ordering (newest first), a hard row cap (max 2000), the event shape, and the non-obvious semantics of side=long. It omits any mention of the `minutes` window or auth/rate-limit behavior, which are the remaining behavioral gaps for a no-annotation tool.

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

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

Three dense sentences with the core scope constraint front-loaded before the routing advice. No filler; every clause either defines scope, semantics, or the alternative 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?

An output schema exists, so return values need not be explained, and the description covers scope, ordering, narrowing, and alternatives. It is nearly complete, with the sole gap being the undocumented `minutes` window parameter.

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

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

Schema description coverage is 0%, so the description must compensate. It adds real meaning for `limit` (max 2000), `symbol` (BTCUSDT example), and `min_usd` (used to look further back), but says nothing about `minutes`, leaving one of four parameters undocumented in both schema and prose.

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 ('Recent liquidation events') plus the return shape (side, price, qty) and ordering (NEWEST FIRST). It names the sibling tools it is not (get_liquidations_summary, get_history), so an agent can distinguish its role without opening other 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?

Explicitly states when to narrow scope ('pass symbol and/or min_usd to look further back') and which alternatives to pick instead for totals or archive access. The note that market-wide 500 rows is 'only a few minutes of a busy hour' gives concrete guidance on when the default is insufficient.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses that totals are a floor due to Binance/Bitget throttling (a real data-quality caveat) and defines side=long semantics. It does not cover auth or rate-limit behavior, and the '[measured]' tag is unexplained, 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?

Front-loaded with the core purpose ('Liquidation totals... already added up') and dense throughout. Every sentence earns its place (alternatives, caveat, param bounds), though the run-on enumeration of outputs is slightly heavy.

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

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

No output schema exists, so the description must describe returns, and it does so well via the rekt/by_symbol/by_exchange/series breakdown. Combined with the throttling caveat and the alternative-tool routing, an agent has enough to call it correctly; only minor gaps (no auth/permission notes) remain.

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

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

Schema coverage is 0% and the single param only shows a default, so the description must compensate. It does: it gives the valid range (1 to 1440) and clarifies that minutes applies to the breakdowns and the series, which the bare schema does not convey.

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 ('liquidation totals... already added up') and enumerates the exact outputs (rekt over 1h/4h/12h/24h split long/short, by_symbol, by_exchange, series). It explicitly distinguishes itself from get_liquidations and get_liquidation_cascades, so an agent can tell them 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?

Explicitly says 'Start here for how much was liquidated' and routes to alternatives by condition: get_liquidations for individual orders, get_liquidation_cascades for events. When-to-use and when-not-to-use are both covered.

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

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

With no annotations, the description carries the full behavioral burden. It does add useful context: the result is 'latest', 'global', and broken down 'per exchange/symbol'. However, it does not explicitly state that this is a read-only operation, what aggregation window is used, or how the data is sourced. This is minimal but not entirely absent.

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

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

The description is a single concise sentence that front-loads the key qualifiers: 'Latest', 'global', 'long/short account ratio', and 'per exchange/symbol'. Every word adds meaning and there is no redundant or filler 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 zero-parameter tool with an output schema present, the description is mostly sufficient. It communicates the metric, scope, and temporal nature. It could be slightly more explicit about whether the response includes all exchanges/symbols at once, but the output schema likely resolves that.

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

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

The tool has zero parameters and the schema has 100% coverage, so there are no parameter semantics to document. The description's mention of 'per exchange/symbol' hints at the shape of the response rather than at input parameters. This matches the baseline for a no-parameter tool.

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

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

The description clearly identifies the resource (global long/short account ratio) and the scope (per exchange/symbol), and the 'Latest' qualifier adds temporal specificity. It does not explicitly include a verb like 'get', but the tool name supplies that. It does not differentiate from sibling market-data tools, so it stops short of a 5.

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

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

No guidance is given about when to use this tool versus alternatives such as get_funding_rates or get_positioning_regime. The description implies it is used for the latest long/short ratio, but it provides no exclusions, prerequisites, or comparison to sibling tools.

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

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

With no annotations, the description carries the burden. It fully discloses the tool's determinism, lack of LLM involvement, and cost (free), which are key behavioral traits. It doesn't explicitly state side effects (e.g., rate limits, idempotency), but for a read-only data tool, this is sufficient.

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

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

The description is a single sentence listing all data components in a comma-separated list, making it dense but efficient. It front-loads the deterministic nature and ends with an actionable use case. No wasted words.

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

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

Given a single optional parameter and no output schema, the description sufficiently outlines what data the tool returns and its purpose. It lacks explicit mention of output format or limitations, but for a data brief tool, the enumerated data points are comprehensive enough.

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

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

Schema coverage is 0%, but there is only one parameter, symbol. The description clarifies that it is a perp symbol and provides a default (BTCUSDT) in the schema, but doesn't add format details (e.g., case sensitivity, supported exchanges). Baseline for low coverage but simple params.

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

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

The description clearly states it provides a deterministic market brief for a perp symbol, enumerating specific data points (liquidations, funding, OI, flows, risk zones, positioning). It distinguishes itself from siblings by emphasizing determinism and no LLM involvement, though it doesn't name a specific sibling.

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

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

It implies use as an input for 'your own reasoning' and is free, but it doesn't explicitly state when to use this over alternatives like get_liquidations or get_open_interest. No exclusions or alternatives are mentioned, but the data scope 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?

With no annotations, the description carries the behavioral disclosure burden. It explains the measurement approach (narrow band around each venue's own mid), the source limitation (only innermost levels), and warns against extrapolation. It does not cover auth, rate limits, or return envelope, which are less critical for this kind of read-only data tool.

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

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

Three tight paragraphs: definition, metric detail, limitation. No filler, and the critical negative scope is placed as a deliberate boundary. Every sentence adds information.

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

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

For a read-only data tool without an output schema, the description is unusually complete about the content and limitations. It falls short only by not explaining the `minutes` parameter or the exact structure of the returned per-minute history, so an agent may still be uncertain how to set the sole argument.

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 documentation coverage is 0% and the description never mentions the only input, `minutes`. An agent must infer that `minutes` controls lookback or history length from context; the description adds no explicit meaning beyond the schema. With one simple optional parameter this is not fatal, but it is a real gap.

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

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

States a specific object ('cross-venue order book microstructure'), the assets (BTC, ETH, SOL), and enumerates the exact metrics returned: spread in bps, immediately-executable depth, bid share, basis, and per-minute spread history. The negative scope statement also makes clear what the tool is not, helping distinguish it from extrapolative market-impact queries.

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 the tool is relevant and explicitly states a when-not: it does not answer 'what moves price 0.5%' because streams only carry innermost levels. It does not, however, name a specific sibling alternative or list conditions that should route an agent to another tool.

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

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

With no annotations provided, the description carries the full burden. It transparently enumerates the response contents (OI in coins/USD, market share %, 1h/4h/24h changes, OI/volume ratio, market totals), giving a clear picture of what the tool computes. It does not disclose data freshness or sort order, but the behavioral disclosure is strong for a read-only reporting 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?

A single dense sentence front-loads the tool's core purpose ('Per-venue open-interest ranking'), then efficiently lists the returned metrics. There is no filler or redundancy; every clause adds value.

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

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

Given a single parameter, no output schema, and no annotations, the description does an excellent job of enumerating the output fields and scope. It could add ordering/freshness details or explain 'market totals' more explicitly, but the essential information needed to understand and invoke the tool is present.

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

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

Schema coverage is 0% and the only parameter is a bare string 'symbol'. The description compensates by specifying it is a perp symbol and providing a concrete example (BTCUSDT), which gives meaningful guidance on the expected value format.

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 pair: 'Per-venue open-interest ranking for a perp symbol' and enumerates the exact metrics returned. The phrase 'per-venue' and 'per exchange' clearly differentiates it from sibling tools like get_open_interest and get_open_interest_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?

The description implies usage: call when you need aggregated OI broken down by exchange, with change % and USD flow. However, it does not explicitly mention when not to use it or name alternative tools, leaving some routing to inference based on sibling names.

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

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

There are no annotations, so the description carries the behavioral burden. It discloses that the output is the latest OI denominated in contracts and USD and organized by exchange/symbol, but it does not mention data coverage, update cadence, or that this is a read-only global snapshot. These omissions are minor given zero parameters, but they keep this at a middling score.

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 hyphenated phrase and no filler; every word contributes either the metric name, units, or granularity. The description is front-loaded and appropriately sized for the tool's simplicity.

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 an output schema, the description is nearly complete: it specifies what data is returned and in what units. It could add a note that no filters are applied and a pointer to get_open_interest_history for time series, but that is more of a usage-guideline enhancement than a completeness blocker.

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

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

The input schema has zero parameters, so there is nothing for the description to explain. The description's mention of exchange/symbol granularity is consistent with a no-argument global query, giving the baseline of 4.

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

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

The description identifies the resource (open interest), the units (contracts and USD), and the granularity (per exchange/symbol), so an agent can tell it is a market-data query. 'Latest' hints at the snapshot nature, though it does not explicitly differentiate from sibling get_open_interest_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?

No guidance is provided about when to choose this over get_open_interest_history, get_oi_board, or other OI tools. The 'latest' qualifier implies a current snapshot, but the description does not state exclusions or alternatives.

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

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

No annotations were provided, so the description carries the burden well: it discloses the output granularity (one row per venue per bucket), the 'measured' provenance tag, and the non-obvious behavior that minutes is 'snapped to a fixed set of windows.' It omits auth/rate-limit/pagination traits, but for a read-only historical query this is solid 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?

Front-loads the core purpose, then routes to alternatives, then documents each parameter. Every clause earns its place; 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?

With an output schema present, return-value explanation is not required, yet the description still usefully names the key columns. Symbol format, minutes bounds, and sibling alternatives are all covered; the only minor gap is that it doesn't state the default of 240 explicitly (though the schema carries 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?

Schema coverage is 0%, so the description must compensate, and it does: it gives the symbol format ('BASEUSDT (BTCUSDT)'), the minutes range (5 to 20160 / 14 days), and the important snapping behavior that the schema does not express. The default value lives in the schema and is not repeated, which is fine.

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 over time for one contract, one row per venue per time bucket.' It also names the two siblings it is NOT (get_oi_board for the current snapshot, get_open_interest for every contract), so an agent can disambiguate without opening any 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?

Explicitly routes the agent: 'Use it to see how positioning built up or unwound; for the current snapshot with shares and 1h/4h/24h changes use get_oi_board, for every contract at once get_open_interest.' Both the use case and the alternative selectors are given.

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

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

With no annotations, the description carries the full burden and does well: it discloses the data source (archived order-book snapshots), the semantic of the output (where bid/ask walls stood and when they were pulled), and the accepted exchange/symbol/time universe. It omits auth/permission needs, rate limits, and snapshot cadence/coverage caveats, which keeps 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?

Front-loaded with the core action and data source, then exclusions, then the parameter universe — a sensible order. It is dense but nearly every clause earns its place; the '[measured]' tag and the grid-field aside add slight clutter.

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

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

No output schema and no annotations, so the description must explain both the call and the return, and it does: the cell shape (time bucket, price bucket, quantity in coins) and the grid-defining fields are all given. Nothing an agent needs to invoke 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 0%, so the description must compensate, and it does: exchange is enumerated (binance | bybit | okx), symbol is restricted to BTCUSDT, ETHUSDT or SOLUSDT only, and minutes is bounded to 1–1440. It even explains the grid parameters (price_min/price_max/price_step/time_step) that give the cells meaning.

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

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

States a precise verb+resource (resting limit orders over time on ONE exchange) and immediately scopes it to archived order-book snapshots producing (time bucket, price bucket, quantity) cells. It names the sibling tools it is NOT (get_liquidation_heatmap, get_footprint), so an agent can disambiguate without opening any 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?

Explicitly routes the agent away with 'not liquidations (see get_liquidation_heatmap for those) and not trades (get_footprint)', which is a clear when-not plus named alternative. Constraints on exchange, symbol and minutes ranges further pin down the applicable context.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It transparently explains the four regime combinations and states exactly what is returned: a market summary plus per-coin price change, OI change, and current OI over the window. It does not discuss rate limits or auth, but for a read-style analytics tool this is sufficient.

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 efficient and front-loaded: it states the core concept first, then explains the regime logic, then lists the return contents. Every sentence adds value, and the four regime explanations are compact despite their density.

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

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

Given the single optional parameter, no annotations, and no output schema, the description is remarkably complete. It covers the input window, the calculation logic, and the full return shape. An agent has enough information to call the tool and interpret its results without additional context.

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

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

Schema coverage is 0%, so the description must compensate. The only parameter, minutes, is indirectly described as 'over the window,' which implies minutes is the lookback window. This adds some meaning beyond the raw schema but does not explicitly define units, allowed range, or how the default interacts with the window.

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

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

The description states a specific verb (get), a specific resource (positioning regime), and the exact construction (price direction crossed with open interest). It distinguishes itself from sibling tools by describing a unique analytical output that no sibling name suggests.

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

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

The description clearly implies when this tool is appropriate: whenever a positioning regime based on price and open interest direction is needed. It does not explicitly name alternatives or exclusions, but the behavior and output are specific enough that an agent can select it appropriately.

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

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

With no annotations, the description carries the disclosure burden. It does well by marking the output as heuristic and specifying the classification categories and decision criterion. It omits some details like data source and side effects, but for an analytical get tool the core behavior is clear.

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

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

A single sentence with no filler; the core concept is front-loaded and the enumerated categories/criterion are dense but 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?

The description explains the heuristic logic, but with no schema descriptions, no output schema, and no usage context, it leaves parameter semantics and selection-vs-siblings incomplete. A tool with three nondescript parameters needs more to be safely invoked beyond defaults.

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

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

Schema description coverage is 0% and the description mentions none of the three parameters (symbol, minutes, exchange). Defaults in the schema are the only hint, so the agent cannot know what 'minutes' means or which exchange values are valid.

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 ('order-book wall lifecycle') and a concrete behavior ('large levels classified as...'), even listing the four output states. This makes it easy to distinguish from sibling market-analysis tools despite not 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 mechanism 'based on whether trades executed into them before they vanished' implies use for spoofing/wall-lifecycle detection, but there is no explicit when-to-use or when-not-to-use guidance and no alternatives named among the sibling tools.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the ~15-min delay, which is a critical data freshness trait, and explicitly lists the data fields returned (price, day change %, range, volume). This gives the agent a clear picture of what to expect. It does not mention read-only status, but that is implied by 'get' and the nature of quotes. It also does not discuss rate limits or authentication, but those are common and not required for a basic quote tool. Overall, it provides meaningful behavioral context beyond the name.

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

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

The description is a single sentence that front-loads the essential information: what is returned, the asset scope, and the key data points. Every element earns its place — the ticker examples, the list of fields, and the delay note. There is no fluff, no repetition, and no unnecessary explanation. It is tightly written and immediately readable.

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

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

Given that the tool has no parameters and no output schema, the description does a good job of conveying the return content and the asset universe. It mentions the delay, which is relevant for usage decisions. It could go slightly further by stating whether the response is a list or a single object, but the listed fields are sufficient for an agent to infer the shape. For a simple quote tool, this is reasonably complete, though not exhaustive.

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 nothing for the description to clarify beyond what the schema already shows (an empty object). Per the rubric, the baseline for 0 parameters is 4, and the description does not introduce any confusing parameter behavior. It adds no parameter-specific semantics because none exist, so the baseline is appropriate.

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

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

The description clearly states a specific verb ('get'), a specific resource ('stocks' limited to crypto-related equities and ETFs), and enumerates the exact tickers (COIN, MSTR, miners) and asset classes. It also lists the data fields (price, day change %, range, volume), which distinguishes it from the sibling tools that focus on derivatives, funding, liquidations, etc. The scope is unambiguous and immediately differentiates it from the rest of the set.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. It does not name any sibling or state conditions like 'use this for equity quotes, not for crypto perps'. The implication is that it is for stock/ETF quotes, but there is no direct statement of when to select it over, for example, get_market_brief or get_top_traders. The agent must infer the use case from the content alone.

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

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

With no annotations, the description carries the behavioral burden. It discloses useful traits: results are limited to upcoming events, sorted nearest-first, and broken down per public vesting schedule. This goes meaningfully beyond the tool name itself, though it does not mention response shape or whether any data source caveats apply.

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 conveys scope, ordering, and output fields with no filler. Every part of the sentence earns its place.

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

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

For a zero-parameter read-only listing tool, the description is complete: it states what data is returned, for which universe, and in what order. There is no output schema, but the description adequately covers return semantics.

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 is effectively complete and there is little for the description to add. The description still clarifies what the returned data represents, which is the relevant semantic context for a parameterless endpoint.

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 ('token unlock events for pool coins'), states the temporal scope ('upcoming'), and specifies output contents ('next unlock timestamp and token amount per public vesting schedule'). It is clearly distinguishable from the many sibling get_* tools, even 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?

The context is clear: use this for upcoming token unlock data for pool coins. It does not explicitly name alternatives or give when-not-to-use conditions, but no sibling appears to cover token unlocks, so the omission is not significant.

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

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

With no annotations, the description carries the burden. It states 'public data' implying a read-only operation, and lists returned fields, but it does not disclose potential limitations such as pagination, count limits, or ordering. It is adequate but not rich.

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

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

The description is a single sentence that front-loads the resource ('Top lead traders') and enumerates the returned data without waste. Every element contributes to understanding what the tool provides.

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

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

For a simple no-parameter tool with no output schema, the description covers the content well: it lists all major fields and specifies the data source. It lacks detail on list structure or count, but that is a minor gap given the tool's simplicity.

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

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

There are zero parameters and an empty schema, so schema coverage is trivially 100%. The description adds no parameter-specific meaning because none exist. Per rubric, a zero-parameter tool gets a baseline of 4, which is appropriate here.

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 'top lead traders' from OKX copy trading, listing specific metrics (total PnL, win rate, AUM, copiers, live open positions with details, and closed trades). This is a distinct resource not covered by any sibling tool, so it distinguishes itself effectively.

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

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

The description implies usage when one needs trader performance data, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. Siblings are all market metrics (funding, liquidations, etc.), so context is clear but no explicit routing is given.

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

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

With no annotations, the description carries the full behavioral burden and does so: it declares read-only, discloses the self-pausing rule (pauses itself at 20 consecutive failures), states the auth requirement (Pro or Bot key from X-API-Key header or api_key argument), and notes that a missing key returns an error object rather than an exception.

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 purpose and scope are front-loaded, then field contents, then auth details, all in one paragraph. It is dense and information-rich with minimal filler, though the run-on field enumeration slightly compresses 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?

With no output schema, no annotations, and one parameter, the description is complete: it documents return fields, delivery-health semantics, auth prerequisites, and error behavior. An agent has everything needed to call and interpret it.

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

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

Schema coverage is 0% and the schema only names 'api_key' with a null default. The description compensates well by explaining both sources (X-API-Key header or the api_key argument) and the consequence of omission, though it does not fully clarify the null default vs. explicit-supply behavior.

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?

It states a specific verb and resource ('The webhook alert subscriptions that belong to the caller's API key'), scopes it to the caller, and enumerates the returned fields. It also names a sibling, delete_alert, making it distinguishable 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?

'Call it to find the id for delete_alert or to check why alerts stopped arriving' gives explicit use conditions tied to concrete tasks. It routes the agent toward the correct follow-up tool rather than leaving usage to inference.

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

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

With no annotations provided, the description carries the burden of explaining behavior. It discloses that the list is 'measured', current ('live open interest right now'), and scoped to BASEUSDT contracts plus the top-100 coin pool. It does not discuss response formatting, but as a read-only listing tool this is a reasonable level of transparency.

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

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

The description is two tight sentences. The first front-loads the tool's output scope; the second supplies the key usage trigger. No filler or redundancy.

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

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

For a zero-parameter discovery tool, the description is complete: it states what is returned, the currency scope, the live status, and the primary use case. No information needed to invoke the tool 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?

The tool has zero parameters, and the schema has 100% coverage, so there is nothing for the description to add. The baseline of 4 applies because no parameter explanation is needed.

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

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

The description specifies exactly what the tool returns: every tracked venue, contracts with live open interest ('BASEUSDT symbols'), and the top-100 coin pool. This clearly differentiates it from the analytical get_* sibling tools, and the name 'list_markets' is backed by concrete output content.

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 explicit guidance: 'Call this first when unsure which symbol or exchange string another tool accepts.' This is a clear, actionable usage context, though it does not name specific alternative tools 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.