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

No annotations are provided, so the description carries the full behavioral burden. It discloses the intended analytical nature and return contents, but does not state permissions, rate limits, latency, data freshness, force_refresh behavior, failure modes, or an explicit read-only guarantee. For a 13-parameter analytics tool, those omissions are a meaningful but not fatal 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 three sentences with no wasted phrasing. Purpose, usage/exclusion, and return information are front-loaded in a logical order, and the dense enumeration in the first sentence is justified by the tool's broad analytical surface.

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?

The description covers selection criteria, sibling alternatives, and the return shape, which is important because no output schema exists. Given the high schema coverage, it is largely complete for a complex 13-parameter tool, though it leaves out operational constraints and some parameter interaction details.

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 92%, so the schema already documents most parameters and sets the baseline at 3. The description adds conceptual grouping around consensus, history, spreads, deviation, correlation, and risk, but it does not clarify key interactions such as metric overriding mode, first-asset behavior for some modes, provider requirements for risk, or force_refresh semantics 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 names a specific verb and resource: 'Run multi-oracle price analytics,' then enumerates consensus, batch reads, historical series, cross-chain spreads, deviation, correlation, and risk summary. It also explicitly distinguishes the tool from get_oracle_price and get_oracle_health, so an agent can identify its scope 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?

It gives explicit when-to-use guidance: 'when one price is not enough' and the caller needs to 'compare, stress or trend oracle data.' It also gives explicit when-not-to-use guidance by naming get_oracle_price for single-provider spot reads and get_oracle_health for feed uptime.

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