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

With no annotations provided, the description carries the full disclosure burden and succeeds: it reveals that USD is the only cross-venue summed unit, base-coin OI stays per venue, contract counts are never served (with the reason: contract size varies 0.01→1000), and that two venues are geo_blocked so the response deliberately does not understate the total. It even states the auth requirement (X-API-Key). No annotation contradicts this.

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?

Every sentence earns its place: the trigger is front-loaded, followed in order by units semantics, data-quality caveats, interpretation guidance, scope clarification, and auth. Roughly 110 words with zero filler, and the geo_blocked disclosure is placed where it matters — as a warning against misreading the total.

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 annotations and no output schema, the description covers a remarkable amount: what the response contains (per-asset OI, total, dominant venue), what it will never contain (contract counts), unit semantics, completeness caveats (geo_blocked), and interpretation. The remaining gaps are minor: the `symbols` parameter format and whether the data is a snapshot versus historical series.

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 partially does: 'per base asset' implies what `symbols` selects, and `asset_class` is fully self-documenting via its single-value enum and default. However, the `symbols` parameter's format (e.g., comma-separated identifiers, symbol conventions) is never specified, and neither parameter is explicitly mapped in the text, leaving 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?

The description opens with a specific trigger ('Call this for LEVERAGE in the system') and precisely defines the deliverable: perpetual open interest per base asset in USD, the total, and the dominant venue. This clearly differentiates it from sibling derivatives tools (funding, basis, vol_surface), and it explicitly names derivatives_funding as a companion tool rather than a substitute.

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 an explicit when-to-use trigger (leverage assessment), explicit pairing guidance ('Pair with derivatives_funding') with concrete interpretation rules (rising OI + rising funding = new longs; rising OI + falling price = new shorts), and an exclusion ('DATA context, not a score') that prevents the agent from treating it as a scoring/signal tool.

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