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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it specifies aggregation across 13 named exchanges, a one-row-per-venue output shape, and the 24-hour change metric. It does not cover auth, rate limits, or update frequency, but for a public read-only analytics tool 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?

The description is a single front-loaded sentence, which is good structure. However, the parenthetical list of 13 exchanges is long and arguably unnecessary for tool selection, bloating the sentence without clear benefit to the agent.

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, single-parameter tool with no output schema, the description adequately explains the return shape and exchange coverage, and annotations carry the safety profile. It still leaves key gaps: no coin format guidance and no when-to-use context. Adequate but incomplete.

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 for the undocumented coin parameter. It only repeats 'for a coin' without specifying symbol format, case sensitivity, or examples, adding essentially no meaning beyond the parameter name itself.

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 (live open interest), scope (summed across 13 exchanges), and output granularity (one row per venue with coins, dollars, share, and 24h change). It is clearly distinct from siblings like get_funding_rates and get_liquidations, but it does not explicitly name an alternative or contrast itself with one.

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 explicit when-to-use, when-not-to-use, or alternative guidance. The agent can infer it is for open interest, but the description gives no context about when this tool should be selected over related market-data tools.

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