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

Annotations declare readOnlyHint and openWorldHint, and the description does not contradict them. It adds behavioral context beyond annotations: the 1000-candle per call limit, default concise output, and options to request full candle arrays via detail or includeCandles. This helps the agent know exactly what to expect in terms of data volume and response format.

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 two sentences long, with the core purpose and key differentiators front-loaded. Every phrase earns its place: it names the data type, the spot market, the comparison with futures, the limit, and the detail options. No fluff or redundancy.

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 the tool's moderate complexity and the absence of an output schema, the description partially covers return format by mentioning OHLCV and 'array candle penuh' for full detail. It also references documentation for the detail parameter, but the description itself could more explicitly describe the default summary structure. It covers essential constraints (max 1000) and options, so it's adequate but not exhaustive.

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 100%, so the baseline is 3. The description adds value by explaining the trade-off between summary and full detail, and by highlighting the deprecated includeCandles in favor of detail. However, it doesn't dive deeper into parameter syntax beyond what the schema already provides, so it earns a 4 rather than 5.

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?

Description clearly states this tool fetches spot OHLCV candlestick data per timeframe, explicitly identifying it as the Spot version of binance_get_klines. It distinguishes itself from futures and other kline tools by noting the 1000 candle limit and the purpose of comparing spot vs futures for leverage detection.

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 explicitly states when to use this tool: to access spot market data, and to compare with the futures version (binance_get_klines) to detect leverage-driven moves. It also differentiates the max limits (1000 vs 1500), giving concrete guidance on when this is the appropriate choice.

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