binance_spot_klines

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

The description discloses several behaviors: batch fetching for more data, millisecond timestamp format, and potential data delays during maintenance. However, it states '单次最多返回1500根K线' while the input schema sets the limit maximum to 1000. This direct contradiction with the schema is a serious transparency flaw that could lead an agent to request an invalid limit, making the description unreliable.

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 overly verbose, using emojis, marketing language ('技术分析利器'), and an extensive illustrative output example with technical tips (e.g., '上影线较短'). While it is structured into sections, much of the content is not necessary for an agent to select or invoke the tool, and it repeats information already present in the schema.

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 covers purpose, usage scenarios, limitations, and provides a detailed output example, which is helpful given the lack of an output schema. However, the example is a formatted text representation rather than the actual API response structure (array of kline arrays), leaving uncertainty about exact return fields. The incorrect limit also undermines completeness. Overall, it is moderately complete but not fully reliable.

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?

The input schema has 100% coverage with detailed descriptions for all 5 parameters, so the description does not need to compensate. However, the description adds little beyond repeating interval meanings and offering analysis advice, and it actively misinforms the limit parameter by citing 1500 instead of the schema's max 1000. This reduces trust in parameter handling despite the schema richness.

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 clearly states it fetches spot market candlestick (K-line) historical data, with a specific verb ('获取') and resource ('现货市场的K线'). It explicitly says '现货市场', distinguishing it from futures_klines, and describes the data contents (open, high, low, close, volume). This fully clarifies the tool's purpose.

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 lists concrete use cases (technical analysis, backtesting, trade planning) and recommends interval choices (short-term 1m/5m, long-term 1d/1w). It does not explicitly mention alternatives like futures_klines, but the spot-market emphasis and sibling tool names imply when to use this vs other tools. No exclusions are given, but the context is clear.

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