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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered; the description adds real substance beyond that: a 10-minute sampling cadence, the comparison venues, and the specific dimensions measured (diff %, snapshot age, 24h mean/max). It does not describe pagination, time-range scoping, or staleness thresholds for the audit itself, which keeps it below a 5.

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

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

Two sentences, front-loaded with the core claim ('The public accuracy audit') followed by supporting detail, then the usage caveat. The parenthetical of metrics is dense but functional; the '[measured]' tag and compressed phrasing add minor noise without wasting a 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 carries the burden of telling an agent what comes back, and it does so at a conceptual level — per-venue diff %, snapshot age, 24h mean/max, and liquidation-map scoring results. It is adequate for a zero-parameter read tool, though exact field names, units and coverage windows remain unspecified.

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

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

The input schema has zero properties, so there are no parameter semantics to explain and no risk of under-documenting arguments. The baseline of 4 applies; the description correctly implies this is a global, parameterless snapshot rather than a filtered query.

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 — a public accuracy audit comparing this service's open interest and funding against Binance, Bybit, OKX and Hyperliquid endpoints — plus a second component scoring the modeled liquidation map against realized liquidations. That is clearly distinguishable from data siblings like get_open_interest, get_funding_rates or get_liquidation_map, which return the raw values this tool validates.

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 an explicit trigger for consulting the tool — 'Read this before trusting any number here with money' — which frames it as a trust/validation step prior to acting on other data. It stops short of naming the sibling tools whose outputs are being audited or stating any exclusion, so the routing is implied rather than spelled out.

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