Liqwall market data

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

Annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds meaningful behavioral context by detailing the returned values: current Binance funding rates, cross-exchange average per 8 hours, open interest in USD with 24-hour and 1-hour changes, Binance long-account share, long/short ratio, and top-trader positioning. It does not discuss rate limits or error behavior, but the output semantics are well covered.

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

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

The description is front-loaded with purpose, then usage examples, then return details. Although the final sentence is dense, every part provides useful information not found in the schema and there is no filler.

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

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

Given the simple one-parameter schema, the absence of an output schema, and the read-only annotations, the description is complete enough for an agent to select and invoke the tool correctly. It explains the scope, use cases, and returns in sufficient 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?

The schema already documents the single parameter at 100% coverage, including the coin symbol and the default to the top ten. The description adds useful context by specifying that the top ten are ranked by open interest and gives an example coin, but this is incremental over the schema.

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

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

The description clearly identifies the resource and metrics: funding rates, open interest, and long/short ratio for perpetual futures, scoped to one coin or the ten largest. It distinguishes itself implicitly from the sibling tools (which cover sentiment and liquidations) but does not explicitly name or contrast those alternatives.

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

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

It gives concrete example questions that show when to use the tool and explains the two coverage modes (single coin or top ten by open interest). It does not name alternative tools or exclusion cases, but the intended use is clear.

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

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

Annotations already establish read-only, idempotent, closed-world behavior, so the description's contribution is the returned content: a 0–100 scale with defined anchors and values from one day, one week, and one month ago. It does not describe output shape or limits, but adds useful behavioral context beyond the annotations.

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

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

One sentence, front-loaded with the resource and its scale, with no redundant or wasted phrasing.

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

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

For a simple one-parameter read with rich annotations and complete schema coverage, the description sufficiently explains the metric, scale, supported scopes, and historical snapshots. Even without an output schema, the return content is adequately summarized for an agent 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 100% and the single optional coin parameter is fully documented there. The description restates the whole-market/BTC/ETH/SOL choices but adds no validation, case sensitivity, or default details beyond what the schema already provides.

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

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

Names the specific index, its 0–100 scale, and the supported scopes (whole market, BTC, ETH, SOL). It is clearly a market-sentiment lookup and is easily distinguishable from the derivatives and liquidation siblings.

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

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

The description implies use for checking current market sentiment and shows the available scopes, but gives no explicit when-to-use/when-not-to-use guidance or named alternatives. For a standalone lookup with unrelated siblings this is adequate but not strong.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds real context: it returns one current snapshot rather than history, names the upstream sources, and discloses the fallback behavior for an unknown market (returns the valid list). It doesn't cover rate limits or snapshot staleness, 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?

Front-loaded with what is measured and where, followed by usage examples and return shape — a sensible order. Slightly redundant: Hyperliquid appears both as a source and again inside the exchange list, and the parenthetical venue catalogs are long for the value they add.

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

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

For a single-parameter read-only tool with no output schema, the description covers sources, snapshot semantics, return contents and error behavior — enough to call it correctly. The one real omission is disambiguation from the 'liquidations' sibling.

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

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

Schema description coverage is 100% and the single 'coin' parameter is already documented richly (tickers, Hyperliquid markets, accepted names and pair forms). The description adds nothing about the parameter beyond that, so baseline 3 applies.

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

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

Specific: it states the exact data returned (USD long liquidations below price, shorts above, nearest clusters) and the venues covered. However, a sibling tool literally named 'liquidations' exists and the description never explains how this differs from it, so an agent must guess between 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?

Gives three concrete example questions ('where are the liquidation levels for BTC', 'where do longs get liquidated', 'what is the nearest liquidation cluster') that clearly anchor the use case. It stops short of exclusions or naming the sibling 'liquidations' as the alternative for historical/aggregate data.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by explaining return content: totals, split by coin or exchange, largest liquidations of the last hour, and a page URL.

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 metric and time windows, then supplies usage examples, then summarizes the return payload. It is dense but every clause contributes useful information.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description supplies enough return-shape detail and usage examples for an agent to invoke it correctly. Nothing essential is missing.

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

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

Schema description coverage is 100%, and the coin parameter is fully documented in the schema with allowed values and omission behavior. The description reinforces that omission means whole market and that the output split changes for one coin, but it does not add syntax or format details beyond the schema.

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

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

The description gives a specific measure ('How much was liquidated') with scope details: last 24 hours, last hour, longs vs shorts, and whole market vs one coin. It is clear what the tool does, but it does not explicitly contrast itself with the sibling liquidation_map tool.

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

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

It provides concrete example questions such as 'how much was liquidated today' and 'were longs or shorts liquidated', which clearly signals when the tool is appropriate. It does not state when not to use it or name alternatives, so it falls short of full alternative guidance.

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