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

No annotations are supplied, so the description carries the full burden, and it discloses unusually useful behavior beyond the signature: the union of stored and live data (provenance and freshness), oldest-first ordering, the exact return shape {t,o,h,l,c,v}, and the pagination continuation field olderEndTime. It stops short of saying whether the operation is read-only, what happens for an unknown or newly listed symbol, or any rate/cost constraints, so it is strong but not exhaustive.

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?

Front-loaded with the distinguishing claim ('no gap up to now'), then provenance, then return contract, then paging, then the sibling comparison. Every sentence carries information an agent would otherwise have to guess, and there is no restatement of the tool name or filler.

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 six parameters, no output schema, and no annotations, this description supplies exactly what structured fields cannot: the data provenance, the ordering, the element shape of each candle, and the paging protocol. Nothing an agent needs in order to call it correctly and page through results appears to be missing.

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 already 100%, so the baseline is 3, but the description adds real meaning on top: limit is framed as the latest N candles returned oldest-first, endTime is tied to the olderEndTime paging loop, and includeFunding is described as adding hourly funding rates for the same window. interval and startTime get no narrative treatment, leaving that half of the semantics to the schema.

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 and resource ('Long price history for one Hyperliquid perp') and pins the scope precisely: stored candles synced daily plus live candles since the last sync, so there is no gap to now. An agent can tell immediately this is the deep-history tool rather than a snapshot tool, and the sibling get_hyperliquid_market is named as the shallow alternative.

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 explicit routing guidance: 'Use get_hyperliquid_market for a quick recent look, this for research,' which names the alternative and the condition that selects it. It also supplies the operational guideline that matters most for a paged tool: when olderEndTime is returned, pass it as endTime to page back.

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