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

Annotations declare readOnlyHint=true, and the description aligns with that. It adds valuable behavioral context: the computation is local from real candles, not a vendor black box; the market routing fallback (spot preferred, perp fallback) is disclosed; and the AltFINS level append is conditional on feed availability. These details reveal dependencies and failure modes beyond the annotation's simple read-only flag.

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 intentionally dense but never redundant. It front-loads the main purpose and indicator list, then explains parameter behavior, then concludes with the conditional AltFINS feed. Each sentence earns its place, though the first sentence is long and could overwhelm an agent scanning quickly. Still, the structure is logical and efficient for the complexity.

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 that an output schema exists, the description doesn't need to detail return structures. It covers parameter semantics, defaults, external data dependency, and a downstream consumer. It is sufficiently complete for an agent to invoke the tool correctly and understand what data will be returned and how the computation differs from alternatives.

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 100%, so the baseline is 3. The description adds meaning by clarifying that 'intervals' picks timeframes with a default and max of 4, and that 'market' routes candle choice with specific options and a default behavior. It also provides a concrete symbol example ('ETH'). This goes beyond simply restating the schema, though it doesn't elaborate on every fixed indicator parameter.

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, informative purpose: 'Multi-timeframe technical-analysis snapshot for one coin.' It enumerates the exact indicators and analytics (RSI, EMA, MACD, ATR, Bollinger, ADX, volume, trend rule), making it unmistakable what the tool returns. It also differentiates itself by noting it is 'computed locally from real candles (not a vendor black box),' which distinguishes it from any opaque analytics sibling.

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 provides clear context on what the tool does and how to configure it with defaults and allowed values for 'intervals' and 'market'. It references 'feed risk_position_size' as a downstream consumer of ATR stop suggestions, hinting at how outputs can be chained. However, it does not explicitly state when to prefer this tool over siblings like market_candles or market_quotes, or when not to use it.

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