LiqSonar

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description's job is to add context — which it does by disclosing the methodology (open interest changes across exchanges plus typical leverage), the 'estimated' nature of the values, and the filtering behavior ('only bins with liquidity are returned'). It stops short of describing error cases or what an empty result means.

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

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

Three tight sentences, scope first, then the interpretive rule, then the return-filter caveat. Zero redundant restatement of the title or schema.

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

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

With no output schema, the description carries the burden of describing the return shape, and it does so adequately (USD per price bin, ±12% window, sparse bins omitted). It could still say something about units or bin granularity, so it is strong but 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?

Schema description coverage is 100%, so both parameters (symbol, days enum) are already documented in the schema. The description only adds that the scope is 'one pair' and the ±12% band, which is output semantics rather than parameter guidance; baseline 3 applies.

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

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

States a specific verb+resource ('Estimated USD of long and short liquidations per price bin within ±12% of the current price for one pair') and adds the semantic orientation rule (longs below price, shorts above) that makes it distinguishable from price-structure siblings like get_order_book_walls. An agent can tell what it returns without opening the schema.

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

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

The scope is clear ('for one pair', ±12% band), which implies when the tool is applicable, but there is no explicit when-to-use/when-not or comparison against siblings such as get_order_book_walls or get_verdict. Usage is inferable rather than stated.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, and the description adds useful behavioral context beyond that: it is a latest-snapshot read, results are ordered largest-first, and side/price/size/distance/duration metrics are defined. It does not discuss rate limits or empty-result behavior, but the key behavioral semantics are disclosed.

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

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

The description is a single dense sentence with the core resource and ordering front-loaded, followed by return-field semantics. Every phrase adds information and there is no redundant repetition.

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

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

With no output schema, the description usefully enumerates the return fields and their meanings, and the schema fully documents all parameters. It is nearly complete for invoking the tool correctly, though it does not clarify sibling selection or edge cases such as no qualifying walls.

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

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

Schema description coverage is 100%, so all five parameters are already documented. The description adds some conceptual meaning for side (bid = buy wall below price, ask = sell wall above) and clarifies distance/size semantics, but most parameter meaning is carried by the schema, so the baseline 3 is appropriate.

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

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

The description states a specific resource and scope: large resting limit orders (walls) in the latest futures order book snapshot, sorted largest first. It is clear what the tool returns, but it does not explicitly differentiate itself from sibling tools such as get_liquidation_levels or get_signals.

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

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

The description implies the tool is for inspecting current order-book liquidity, but it gives no explicit when-to-use guidance, no exclusions, and no alternatives. An agent must infer the use case from the resource name and return fields.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description still adds real value by disclosing the ordering and the conditional presence of AI summaries ('when one exists'). It stops short of noting pagination, result totals, or how 'detected' events are qualified.

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, front-loaded with what the tool returns before the field enumeration. The long listing of metrics earns its place because no output schema exists, though it reads as a run-on rather than a structured list.

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

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

With no output schema, the description carries the burden of describing return content and does so thoroughly, and annotations cover safety. Gaps are minor: no mention of whether results are limited by available data, deduplication, or how to page beyond the limit.

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

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

Schema coverage is 100%, so all three parameters (days, limit, language) are already documented with defaults and bounds. The description only indirectly touches them by mentioning AI summaries, which hints at the language parameter, so baseline 3 applies.

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

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

Names a specific resource (detected pump and dump events) with an explicit scope (Binance futures) and ordering (newest first). The enumeration of returned fields makes it unmistakable against siblings such as get_liquidation_levels or get_order_book_walls, which cover entirely different market phenomena.

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

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

There is no guidance on when to reach for this tool versus the four sibling signal tools, nor when-not to. 'Newest first' describes output ordering rather than selection criteria, and nothing tells the agent how to choose days or limit.

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 readOnlyHint and openWorldHint already covering the safety profile, the description still adds real value: return fields (severity, price change, CVD, English detail), result ordering, and an honest warning that thresholds are uncalibrated. That calibration caveat is exactly the kind of qualifier annotations can't express.

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

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

Two sentences, front-loaded with the resource and scope, and the caveat placed last where it belongs. The signal-type enumeration is dense but each item is informative; minor verbosity in listing six types.

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, and the description compensates by specifying the fields each signal carries and their ordering. Combined with complete parameter documentation, an agent has what it needs to call and interpret the tool; only the absence of volume/size expectations holds it back.

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 all three parameters (hours, limit, symbol) are fully documented in the schema, so the description carries no additional parameter burden. It adds no semantics beyond the schema, which is the expected baseline at full coverage.

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

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

States a concrete resource (recent order-flow signals on Binance futures), an ordering guarantee (newest first), and enumerates the signal types so an agent can tell this apart from get_liquidation_levels or get_order_book_walls. It stops short of explicitly naming which sibling to use instead, so not a 5.

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

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

The closing caveat ('treat a signal as context rather than a call') gives interpretive guidance on how to use the output, but there is no explicit when-to-use/when-not-to-use framing and no named alternative among get_pumps, get_verdict, or get_order_book_walls. Usage is implied by the signal-type list rather than stated.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds meaningful behavioral context by naming the exchanges, defining what bearish_divergence and bullish_divergence mean, and noting that output includes a short English detail per exchange.

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

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

The description is a single front-loaded sentence with no wasted clauses; every part contributes to defining the verdict categories, exchanges, or output detail. It is dense but appropriately sized for the tool.

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

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

With no output schema, the description does useful work by enumerating the possible verdicts and stating that a short English detail is returned per exchange. It does not specify the exact response object structure, but it gives enough for an agent to understand what will come back.

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

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

Schema description coverage is 100%, so both symbol and hours are fully documented in the schema. The description only loosely reinforces the 'one pair' and 'last hours' concepts without adding syntax or format 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?

The description states a specific analytical operation: for one pair, it reports whether price moves with or against CVD order flow across four named exchanges over the last hours. It enumerates the exact verdict categories and even defines the divergence cases, making its purpose clearly distinct from sibling tools like get_liquidation_levels or get_order_book_walls.

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

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

Usage is implied by the phrase 'For one pair... over the last hours,' which tells the agent the scope and time window, but there is no explicit guidance on when to choose this tool versus get_signals or get_pumps, and no stated exclusions.

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