RSI heatmap: Wilder RSI(14) on eight timeframes for the top-400 crypto perps and every TradFi perp

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 and the description is free to spend its words elsewhere. It does exactly that: live board scope, the top-400 volume cutoff, the default 30-row window, the 400-row ceiling, and the semantics of asc vs desc ordering. What it omits is refresh cadence and per-row field composition, which is meaningful but secondary for a read-only board.

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 trigger is front-loaded in the first clause, followed by return scope, then filtering/sorting, then pagination defaults, which is a sensible information order. It is a single dense paragraph with no filler sentences. A light break into trigger / returns / paging would have made it scannable rather than a run-on.

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?

There is no output schema, so the description correctly carries return-value burden by stating that it returns the live board plus overbought/oversold counts per interval. Combined with the fully documented 5-parameter schema and read-only annotations, an agent has enough to invoke it correctly. Remaining gaps are refinement-level: the per-symbol row shape and what happens if symbol is outside the top-400 universe.

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 per-parameter baseline is already a 3. The description goes beyond the schema by explaining parameter interaction: that limit only matters in the absence of symbol, that the default slice is volume-ordered unless sort is given, and that order asc combined with sort yields most-oversold-first. That crossover behavior is not stated in the schema and is where mis-calls would otherwise happen.

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 concrete resource and metric (Wilder RSI(14) heatmap across eight named timeframes) over a defined universe (top-400 Binance crypto perps by volume plus every TradFi perp). That level of specificity separates it cleanly from lookalike siblings such as get_funding_heatmap, get_tradfi_board and get_top_movers without opening any 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?

The opening clause gives explicit trigger conditions ('when the user asks which coins are overbought or oversold', multi-timeframe RSI, or one contract's RSI on a named interval), which is strong when-to-use guidance. It also explains the default path (no symbol -> first 30 rows) and the escalation path (limit up to 400, order asc + sort for most oversold first). It stops short of naming when-not-to-use or a specific alternative sibling, which keeps it off a 5.

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