analyze_structure

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

With no annotations provided, the description carries the full burden. It clearly states this is a read operation, describes what data is fetched (candles from Hyperliquid's public endpoint), what is returned, and how include_candles changes the response. It does not explicitly mention side effects or rate limits, but 'Read' plus the public endpoint implies a safe, non-destructive operation.

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 well structured and front-loaded: a one-sentence summary, followed by return details and input-mode guidance. Every sentence adds useful information, with no filler or repetition. Despite being longer than a minimal description, it is appropriately sized for a tool with multiple input modes and output details.

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 is largely complete given the output schema exists and no annotations are present. It covers the tool's purpose, output, input modes, and a key flag. The only notable gaps are the exact semantics of limit and interval, which are optional and have defaults, so an agent can still invoke the tool correctly without full understanding of those parameters.

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 explains coin, candles, and include_candles well. However, limit and interval are not clearly defined: interval is only hinted at via 'ETH-15m data' and 'same time scale as the levels,' and limit is not mentioned at all. This leaves meaningful ambiguity for two of five parameters.

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 uses a specific verb and resource: 'Read market structure,' and enumerates exactly what is returned: trend, ChoCh/BOS breaks, swing highs/lows, potential swing levels, and impulse peak/trough. This clearly distinguishes it from sibling tools like find_liquidity_sweeps and find_blocks, which target different market concepts.

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?

The description gives clear context for when to use the tool: to read trend and structural breaks. It also explains the three input modes (coin, custom candles, or neither for a worked example) and when to set include_candles=true. It does not explicitly contrast with sibling tools, but the purpose is distinct enough that an agent can select it appropriately.

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