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

The read-only/open-world annotations already cover safety, and the description adds value by explaining that closing prices are used as the net-value series, results are negative numbers, peak positions are returned, and larger windows approach historical extremes. No contradictions with annotations.

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?

Two succinct sentences, no redundancy; the first sentence states the operation, the second gives actionable guidance. Every sentence earns its place.

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 tool is simple, has an output schema for return details, and the description gives the key use recommendation. It is complete enough for an agent to invoke it correctly, though it could strengthen explicit routing away from account-performance tools.

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 matters. It communicates the recommended interval limit 1d×365 and connects 'window' to limit, but it does not directly explain symbol or interval beyond the schema enum. It partially compensates for the missing parameter descriptions.

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 identifies a specific verb and resource: fetching K-line data and calculating the asset's maximum drawdown and peak-trough positions. It also explicitly notes that this is not account performance, which distinguishes it from analysis_sharpe and analysis_var.

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?

It provides clear practical context for how to choose the window: 'larger windows approach historical extremes; suggest starting at 1d×365'. It does not name alternatives, but the 'non account performance' note acts as a when-not-to-use signal.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true. Beyond that, the description discloses the derivation path ('拉取 K 线推导收益率'), what is computed ('年化收益/波动、夏普与索提诺'), and the auto-inference behavior of periodPerYear. It also discloses the limitation that small windows have limited statistical meaning, which is honest and useful. This is more than annotations provide.

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 compact and information-dense: three sentences, each contributing a distinct semantic block (what it computes, what it measures, how periodPerYear is defaulted, and a usage caveat). It is well-structured for an AI consumer.

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 explains the core behavior, the derivation approach, the parameter defaulting strategy, and a statistical caution. It doesn't describe the return value shape beyond an available output schema, so the output_schema likely covers that. Missing details such as how to treat riskFreeRate defaults or exact timezone conventions are minor against the available annotations and schema.

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 schema's description coverage is about 40% (only periodPerYear and riskFreeRate have descriptions). The description adds meaning by explaining the default behavior of periodPerYear (auto-inferred by interval) and the meaning of riskFreeRate remains opaque, but the description doesn't detail all five parameters. It adds semantics for the timing, but not the format of symbol, limit, or riskFreeRate; the schema already provides some parameter domains. The description partially compensates for the schema gaps.

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 states a specific verb ('拉取 K 线推导标的收益率序列') and resource ('标的收益率'), and explicitly scopes the metric to '标的价格序列的风险特征（非账户绩效）', distinguishing it from account-focused tools. However, it doesn't name a specific sibling alternative, so differentiation from other analysis/indicator siblings is implicit rather than explicit.

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 clearly scopes the tool to '标的收益率序列' and explicitly excludes '账户绩效', noting that 'serious evaluation' should use larger windows. However, it doesn't explicitly describe when to use this tool instead of other indicators/analysis tools, leaving some inference to the agent.

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

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

在注解已有 liveHint=true 与 openWorldHint=true 的基础上，描述补充分传了额外行为：历史模拟法、计算对象为收益率序列、单一 K 线对象的含义，以及重要符号约定'负值=损失'。这些信息能防止把结果直接读作另一层含义，帮助智能体正确理解调用后的结果。

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?

全部内容只有两条有效句子：第一句讲计算对象、方法、结果并通过符号约定；第二句给出阈值且是真正可执行的止损指导。每句都有独立价值，无冗余，起点句在句首，结构紧凑清晰。

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?

在已有输出 schema 以及 readonly/openWorld 注解的前提下，描述已覆盖计算全员向量、统计方法、置信度、结果定义容忍、适用配置六个关键，能让智能体有安全决策所需的信息。只差少量有关结果输出格式与极端置信度（limit 过小）注意事项的更多补充，不给失去完整分。

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 文本覆盖率仅 25%（只有 confidence 有描述），需要描述补齐参数含义。描述通过'K线——收益率——VaR/CVaR'的链路让 symbol 与 interval 的实际角色自然成立，也暗示了 limit 的效率与样本采样意义。虽然没有逐参数列名说明，但已能给充分弥补了 schema 的缺口。

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?

描述正确定义了动词与资源：拉取 K 线推导收益率，按历史模拟法计算置信度下的 VaR 与 CVaR。通过'度量工具后单根 K 线尾部风险，非账户绩效'进一步将它与 analysis_sharpe、analysis_drawdown 等账户/策略类评估分开，属于清晰的用途定义。

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?

明确说明了该工具的核心情境——单根 K 线尾部风险——并提出了参考规则：止损 ≥ 单根 VaR × 杠杆，否则可能被正常波动扫损。'非账户绩效'是对应用范围的明确排除，可视为一种边界说明；缺点是没有直接指出应与哪个具体兄弟工具对比使用中选择。

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

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

The annotations already mark this as read-only and open-world. The description adds useful behavioral detail beyond annotations by stating the internal flow: it fetches K-lines, calculates ADX, and returns a stable sequence. It also clarifies the numeric output domain and that the value is direction-independent, which helps an agent understand what the tool actually returns.

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 one compact sentence that front-loads the tool's access mode and calculation flow, then adds the key context about the output range and interpretation. There is no wasted text or redundant schema re-statement.

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?

For a read-only indicator with output schema and annotations, the description is reasonably complete for a basic call. It does not provide explicit guidance about the period/limit parameters or how to choose this tool over sibling indicators, but the output schema and defaults make an ordinary symbol/interval call feasible.

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 needs to compensate. However, the description only mentions K-lines and ADX, providing no explanation of period (default 14), limit (default 200), or how these affect the calculation and returned series. The agent must infer meaning from parameter names and defaults alone.

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 gives a clear verb and resource: it pulls K-lines and computes ADX, returning a stable trend-strength sequence. The additional context that the result is 0-100 and direction-independent clearly identifies the indicator's purpose, although it does not explicitly distinguish itself from the many sibling indicator tools.

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 implies the tool is appropriate when trend strength is needed regardless of direction, but it does not explicitly say when to use ADX instead of another indicator such as indicator_rsi or indicator_bb. There is no when-not-to-use information or explicit sibling alternative.

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

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

除注解readOnlyHint已经说明只读外，描述额外说明了计算过程（拉取K线、计算ATR）、默认平滑方式（Wilder）和返回特性（稳定序列），这补充了注解之外的实际执行行为。没有与注解矛盾。

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?

描述仅用一句话就包含了类型、计算方式、结果特性和默认参数，语义紧凑，前置了对“直连版”的限定，没有任何冗余。

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?

在已有输出schema和只读注解的加持下，描述基本覆盖了核心调用背景，但“直连版”的设定没有上下文说明，也没有提及与潜在非直连版或交易类工具的边界。对于多工具开放环境，仍有模糊空间，尚算刚刚及格。

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?

当前参数有4个，schema描述覆盖率为0%，描述中几乎没有对参数进行额外解释。只通过“默认Wilder平滑”间接暗示了period的默认风格，但symbol、interval、limit等参数均未在描述中说明对应语义或使用建议，描述未帮助填充schema空白。

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?

明确说明直接获取K线后计算ATR，并指出其为波动率工具，同时提到默认Wilder平滑。与其他指标工具（SMA/EMA/MACD等）在功能上有明显区分，动词和资源明确。

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?

描述中通过“衡量波动”点明了使用场景，且在指标类工具中能自然引导Agent在需要波动率时选择该工具。但未明说何时不应使用或与其他波动率工具的取舍，缺少明确的排除性指引。

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

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

The annotations already mark the tool as read-only and open-world safe. The description adds that it first pulls K-lines and returns a stable triple sequence, which is useful context beyond the annotations. However, it does not clarify what 'stable' means, how limits are applied, or whether the output aligns with the K-line history length, so transparency remains partial.

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 a single, focused sentence with the key behavioral fact and output shape front-loaded. It is concise and easy to parse. It is slightly sparse, but there is no waste or unnecessary repetition.

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?

For a five-parameter indicator tool with no output schema, the description leaves too much unspecified: the meaning and defaults of the parameters, how the returned triple is structured over the K-line window, and how it behaves with different limits. The annotations cover safety but not operational details, so an agent still lacks enough to use the parameters confidently.

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%, and the description does not compensate: it does not explain 'limit', 'period', 'deviationMultiplier', 'symbol', or 'interval'. Although the description ties the calculation to K-lines and the Bollinger output, it provides almost no semantic value for the five parameters, which are critical for correct invocation.

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 states a concrete behavior: it pulls K-line data, computes Bollinger Bands, and returns a lower/middle/upper triple sequence. It goes beyond restating the title and gives the return shape. It does not explicitly differentiate from sibling indicators, though 'direct version' hints at an implementation distinction.

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?

There is no guidance about when to use this tool instead of the many sibling indicator tools such as indicator_bb_rsi or indicator_sma. The phrase '直连版' hints at a direct-vs-composite usage context, but no conditions, alternatives, or exclusions are provided, leaving the agent to guess.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context — it fetches K-line data (拉取 K 线) and performs all computations in one pass — which conveys the dependency on exchange data. However, the term '直连版' is ambiguous and unexplained, and the meaning of '%B 与价格分区' outputs is not clarified, so the added value is moderate rather than strong.

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?

A single Japanese sentence that front-loads the action and lists the computable outputs without any filler or repetition of the input schema. The '直连版' prefix is cryptic and slightly undermines the line, but the rest of the description is economical and well-ordered.

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 output schema exists and covers return values, so that par is not needed here. However, the meaning of '直连版', the mapping of parameters to each sub-computation, and any notion of K线 history depth/limits are missing. plus no hint to differentiate selection from the close sibling indicators. A complete definition for a combined-indicator tool should add these.

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 carries the full burden for explaining parameters, but it does not return an instruction for any parameter: how period relates to BB, how rsiPeriod relates to RSI, what limit governs, or what deviatiate+multiplier does. Only the implicit mapping — K-lines to limit and the BB/RSI sections to the two period parameters — is guessable. For a 6-parameter tool with zero schema coverage, this does not compensate for the gap.

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 specific verb-resource combination: pull K-lines and simultaneously compute full Bollinger Band data, RSI, %B, and price zones, which is clear and distinct from the name alone. It differentiates from siblings like indicator_bbands and indicator_rsi by the '同时' (simultaneously) framing, though the term '直连版' is never explained and the distinction from other combo indicators like MACD+RSI is left implicit.

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?

Usage context is only implied: an agent can infer this tool should be chosen when both Bollinger and RSI are needed simultaneously, and the title supports the combination intent. However, there is no explicit when-to-use statement, no exclusions, and no routing guidance against the many sibling indicators like indicator_bbands, indicator_rsi, or indicator_macd_rsi.

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

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

annotations 已具备 readOnlyHint=true 和 openWorldHint=true，安全画像无需描述额外承担。描述补充了有价值的行为：该工具会自行拉取 K 线数据（'直连版'，暗示每次调用有网络数据成本），并说明输出序列经过典型价离差归一、可正可负，这对输出解读有帮助。但'直连版'与'稳定序列'均为未定义术语，行为信息整体有仍显单薄。

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?

全文一句，简短且关键信息（计算对象、计算方式、输出特性）靠前集中，无明显冗余。'直连版'和'稳定序列'两个术语富有信息量但仍需解释，既保持压缩的评价则不算5。

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?

存在 output schema 和 input 枚举/默认值，承担了返回结构与合法取值的一部分职责，因此描述不必解释返回值字段。但对一个需要 symbol/interval/period/limit 的调用，描述中的参数说明缺失如 period 对计算的影响、limit 对序列长度的行为，'直连版'的语义也未澄清，中等复杂二元完整度仅达基本线。

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 的参数描述覆盖率为 0%，描述必须补偿，但描述几乎未涉及参数。'拉取K线'间接指向 symbol 与 interval，却完全没有说明 period 的含义（只能凭默认值20和CCI常识硬推），limit 更是完全未提及。对 0% 覆盖率的 schema 来说，这是明显的补偿缺口。

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?

描述明确说明了动作（拉取K线后计算CCI）和结果（返回归一化、可正可负的稳定序列），并交代了计算口径（以典型价离差归一），不是对工具名的简单复述。但未与同组大量 indicator_* 兄弟工具做任何区分，依赖工具名自身传达'这是CCI指标'，因此不足5分。

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?

描述只说明了工具做什么（拉K线算CCI），没有给出任何'何时用本工具而非替代品'的指引。面对 indicator_multi、indicator_macd_rsi、indicator_bb_rsi 等复合工具，以及十余个单指标工具，描述未说明何时应选 CCI、何时应选其他指标或复合工具。'直连版'一词似乎暗示存在非直连版本，但没有解释其适用取舍，属于不完整或无用的指引。

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral detail beyond that: it internally pulls K-lines ('拉取 K线后检测') and explains the half-window extreme-comparison algorithm, so the agent knows the tool has internal data dependencies and what computation drives the result. No contradiction with the read-only annotations.

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?

A single compact Chinese sentence conveys purpose, pipeline (K-line fetch --> detect), and return concept (divergence type + extreme details) with little waste. A very small deduction for the '直连版' prefix, which may confuse agents by hinting at a nonexistent sibling version.

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 has 5 parameters, covers output schema, and a read-only annotation, the description covers the core 'what' and 'algorithm' but not edge behavior (e.g., what happens when there is insufficient data, how many divergence results are returned, or the relation between lookback/limit/rsiPeriod. An agent can call it correctly with schema-provided defaults, but may be surprised by edge-case results.

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 only 20% (only lookback is explained), so the description should compensate. It partially does: '前后半窗极值对比' gives context for lookback's window semantics. But rsiPeriod, limit, symbol, interval and their interplay are not elaborated in either the schema or the description, and defaults (14/200/20) are standard enough that agents are likely to call correctly without further detail.

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?

States a specific verb+resource: it detects price-vs-RSI top/bottom divergence ('检测价格与 RSI 的顶背离 / 底背离'). The '前後半窗极值对比' mechanism makes the function concrete, and divergence is a unique concept among the indicator siblings, distinguishing it from indicator_rsi, indicator_macd, etc. It loses a point only because it never explicitly names an alternative or a differentiation against the other indicator tools.

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 intended use — проверка divergence between price and RSI — is clear, so when an agent needs divergence detectentation this tool is the obvious choice. But there is no guidance on when NOT to use it, no mention of raw-als indicators like indicator_rsi for plain RSI values, and no statement about alert-window tuning. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, so the tool's non-destructive nature is known. The description adds context by revealing that the tool pulls K-lines internally and uses the first price as the smoothing seed, but it does not specify behavior for insufficient data or limit/period pitfalls. No contradiction exists.

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?

It is a single front-loaded sentence that introduces the main action before modifiers, and adds only concise formula-relevant detail. The term "直连版" is a slight ambiguity that could be clearer, so it is not a perfect score.

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 output schema and read-only annotation covered return structure and safety, and the description covers the core algorithm. However, with four poorly specified parameters, no sibling differentiation, and no usage alternatives, the definition does not fully equip an agent to choose and calibrate the call across similar indicators.

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 supply parameter meaning. It only elaborates on period, calling it the周期, and gives the smoothing-seed behavior; it does not explain limit, interval usage, or how symbol/interval parameterize the K-line pull. This leaves much of the parameter understanding to inference.

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 states a clear operation and resource: "拉取 K 线后计算指数移动平均" and returns an "EMA 序列". It also gives a useful formula detail (first price as smoothing seed). It does not explicitly contrast with sibling tools like indicator_sma or indicator_macd, which prevents a 5.

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 no when-to-use direction, no stated preference compared to other indicator tools, and no examples of scenarios where EMA is appropriate. The only contextual phrase "直连版" is ambiguous and does not explain selection between this and sibling indicators.

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

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

The description adds some behavioral context beyond the annotations by revealing that the tool pulls K-lines, computes MACD, and returns a stable sequence of triples. The annotations already cover read-only and open-world hints, so the burden is lower. However, it does not mention edge cases, error conditions, or how the return sequence is structured relative to time or limit.

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 a single short sentence that front-loads the core behavior (K-line fetch, MACD calculation, output shape). Every phrase earns its place, though the '直连版本' wording is fuzzy and consumes space without being fully informative.

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 schema coverage of 0%, six parameters, and a sibling ecosystem full of choosing ambiguity, this description is far from complete. It provides an output shape, so the output schema can carry some burden, but it totally fails to explain parameter semantics or give usage context, making the tool under-specified for an correct invocation.

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%, and the description does not mention or explain any of the 6 parameters. Even the key MACD parameters like longPeriod, shortPeriod, and signalPeriod are omitted entirely, so the agent receives no semantic explanation for the parameters beyond raw schema defaults.

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 states a specific verb and resource ('拉取 K 线后计算 MACD') and identifies the output as a stable triple sequence (macd / signal / histogram). '直连版' hints at a distinguishing mode and distinguishes this from combined indicator siblings like indicator_macd_rsi, though the meaning of '直连版' is not fully explained.

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?

No guidance is provided on when to use this tool instead of the many sibling indicators (e.g., indicator_macd_rsi, indicator_multi, indicator_rsi). The phrase '直连版' implies some mode difference, but it never states when an agent should choose this tool or when it should not. There is no explicit exclusions or alternatives.

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

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

annotations 已提供 readOnlyHint=true 和 openWorldHint=true；描述额外说明该工具会先拉取 K 线再计算指标并返回完整数据，且不会产生主观信号，这增加了对调用行为和输出边界的透明性。

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?

描述只有一句话，结构紧凑且信息密度高：先讲数据来源，再讲计算内容，再讲返回方式，最后标注边界。没有冗余或重复 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?

有输出 schema 和 readOnly annotations 的情况下，工具行为的核心部分得到覆盖；但该工具参数较多，且描述既未解释参数语义，也未提供使用边界或替代工具指引，整体上下文仍不够完整。

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 参数覆盖率为 0%，描述也没有说明 fast、slow、signal、rsiPeriod、limit 等参数的含义或默认值关系。对于 7 个参数的组合指标工具，参数语义完全缺失，描述本身无法帮助 Agent 理解除符号和时间周期外的输入。

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?

描述明确说明了工具动作：拉取 K 线后计算 MACD 与 RSI 的最新值，并指出返回完整数据、不输出主观信号。结合工具名“MACD + RSI 组合”可以看出它区别于单独计算 MACD 或 RSI 的兄弟工具，但没有显式点名区分边界。

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?

描述中没有给出“何时应该使用本工具、何时应改用 indicator_macd/indicator_rsi/indicator_multi”等指引。“不输出主观信号”只是对输出的限制，不是调用时机的指导。

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

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

Annotations already mark this as read-only and open-world, so the safety profile is known. The description adds meaningful behavioral context by stating that it fetches K-lines before computing crossover status and that it produces a directional bias classification, which goes beyond the annotations.

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 a single concise sentence that front-loads the tool identity and immediately lists the key output categories. There is no redundant writing or repetition of schema defaults.

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?

With an output schema and readOnly annotations, the description does not need to repeat return values or safety guarantees. However, given six parameters and low schema coverage, the description is thin on parameter-level context and does not help an agent decide between this and related indicator tools. It is minimally sufficient but not fully complete.

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 very low at 17%, and the description only vaguely compensates by mentioning "dual moving average." It does not explain how fast, slow, type, limit, symbol, or interval interact, nor does it clarify fast vs slow behavior. Schema fields like symbol and interval are self-explanatory, but the important indicator parameters remain under-documented.

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 a specific action and resource: it pulls K-line data and detects dual moving average crossover state, listing explicit outputs (golden_cross / death_cross / none) and bullish/bearish bias. This distinguishes it from sibling tools like indicator_sma, indicator_ema, and indicator_macd, which either return raw indicator values or use a different construction.

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 implies its use case: an agent should call this when the user wants dual moving average crossover detection. However, it gives no explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools such as indicator_macd or indicator_multi for similar signal detection.

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

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

Annotations already indicate read-only behavior, and the description adds meaningful context about the data source (K-line pull) and the output format (stable 0-100 series). It does not contradict the annotations and adds transparency beyond them, though it omits edge cases or failure behavior.

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?

A single compact sentence that packs the action, formula basis, and output range without redundancy. It is appropriately front-loaded with the operation and delivers high information density.

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 tool is a standard technical indicator with an output schema, so the return structure is already covered. The description adds the key conceptual distinction (volume-weighted RSI) and data dependency (requires K-lines), which is nearly sufficient for correct invocation by an agent familiar with MFI.

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%, and the description does not explain any of the four parameters. Even common MFI semantics like 'period' as lookback window or 'limit' as data length are left completely implicit, forcing the agent to rely on naming heuristics.

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 the action: pull K-lines and compute MFI, returning a bounded 0-100 series that is a volume-weighted RSI variant. This makes the tool's purpose unambiguous, though it does not explicitly distinguish it from sibling indicators by name.

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?

No guidance is provided on when to use this tool versus alternative indicator tools such as indicator_rsi or indicator_obv. The phrase '直连版' hints at a variant but does not explain trade-offs or selection criteria.

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

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

annotation已经标记readOnlyHint和openWorldHint，描述不需要重复安全说明。描述额外补充了“直接拉K线”“只算最新值”“一次网络往返间接完成多个指标计算”，这些不是schema能直接看出的行为上下文，很有价值。

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?

两句中文，先给最核心的用途，再给可选参数，最后给网络收益。没有任何冗余句子，信息密度很高。

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?

在存在输出schema、readOnlyHint且参数schema已含default/enum/range的情况下，描述已经覆盖了“何时用、算什么、有哪些可选开关和最大收益”，没有明显缺口。选择正确的所需信息已足够。

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，覆盖率为0%，而描述主动讲解了默认指标周期和includeATR/includeADX/includeStoch三个布尔参数的含义。但没有说明limit对指标 lookback 窗口的具体影响，也没显式对应symbol/interval，所以扣掉一分。

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?

明确说明动作是“单次拉取K线，批量计算”，并列出默认计算 RSI(14)+MACD(12/26/9)+BBands(20/2)，可选用ATR/ADX/Stoch。它与indicator_rsi、indicator_macd、indicator_bbands等单个指标工具显著区分，不依赖打开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?

清楚写明“替代逐个调用 3-6 次网络往返”，即当需要多个指标时优先使用本工具。缺点是没有显式说明“如果只需一个指标，应改用单个indicator_*”，所以不算完全满足when-not的边界。

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

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

注释已经声明 readOnlyHint=true 和 openWorldHint=true，工具安全属性已有保障。描述在此基础上补充了它会先拉取 K 线、基于开盘与收盘方向累计成交量的计算逻辑，并指出返回的是‘稳定序列’，这些信息有一定价值。不过没有说明数据缺失、K线不足、边界情况等行为，也只能算中等透明。

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?

描述非常简短，前置说明了核心功能，没有冗余信息。除“直连”一词与为何要“稳定序列”外，整体表达紧凑，值得给较高评分。

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?

有输出 schema 且是只读计算类工具，降低了部分负担，但仍有 4 个参数、0% schema 描述覆盖、且存在大量指标类兄弟工具，描述未提供使用场景、参数含义或与其他指标工具的区别，上下文信息不充分，不足以支持可靠的工具选择与调用决策。

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 的参数描述覆盖率为 0%，且描述文本没有对 symbol、interval、limit、period 四个参数做出进一步解释。描述只提到“先拉取 K 线”，但未说明 period 如何参与 OBV 计算，也未说明 limit 与 period 的关系，agent 无法从描述中获得额外参数语义。

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?

描述明确说明了‘拉取 K 线后计算 OBV’，即该工具的核心动作与计算对象，并指出返回的是结合开盘/收盘方向的累计成交量序列。虽然没有点名区分某个具体兄弟工具，但‘OBV/能量潮’这一指标身份清晰，足以与 VWAP、RSI 等其他指标区分。

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?

描述完全没有说明何时应使用 OBV，而非其他工具，如 MACD、RSI 或成交类指标。多个兄弟指示器之间也没有任何引导或排除关系，仅靠‘直连版’无法帮助 agent 判断该工具最适合的场景。没有提供任何条件或备选项说明。

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

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

注解已声明只读和公开数据访问，描述在此基础上补充了关键运行行为：基于K线计算、使用 Wilder 平滑、输出被限定在 0-100 的稳定序列。没有与注解矛盾，也不需要再说明副作用。

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?

一句话涵盖数据来源、计算方式、输出范围和关键参数，没有冗余。关键信息前置，便于快速定位；对于简单的指标工具，这种长度是合适的。

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?

该工具是相对简单的指标计算工具，且已有输出 schema 和只读注解，描述提供了足够的核心语义，如周期、平滑算法和数值范围。虽缺少参数选型说明和与替代工具的边界，但对调用本身已比较完整。

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 的字段描述覆盖率为 0%，描述也未对 symbol、interval、limit 给出额外语义，只提到“period 为周期”，这基本是参数名本身的同义重复。因此参数意义更多依赖字段命名和交易常识，工具描述补偿不足。

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?

描述直接说明“拉取 K 线后计算 RSI”，给出具体动作、资源与输出特点（0-100、Wilder 平滑），明确区分于其他指标类工具。标题只是指标名称，但描述补充了计算方式和返回序列，使目的非常清晰。

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?

描述没有说明何时应使用本工具，也没有在 RSI 与 MACD/RSI、背离、多指标等其他关联指标之间给出选型指引。“直连版”暗示了一种实现差异，但未解释与替代方案的区别或适用场景。

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

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

The annotations already mark the tool as read-only, so the description's main job is to explain how it behaves beyond safety. It does this by disclosing that the tool itself pulls K-line data before computing the SMA, and returns a stable SMA series. This is meaningful behavioral context, though it could say more about caching or how missing data is handled.

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 a single, front-loaded sentence that directly explains the calculation pipeline and output. There is no filler, repetition, or unnecessary qualification; every clause contributes useful information.

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?

For a simple indicator tool with read-only annotations and an output schema already present, the description is mostly complete. The main gap is the missing explanation of the 'limit' parameter and how the pull length influences the returned SMA series, which is important for a correct invocation.

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 for parameter meanings. It only clarifies that 'period' is the cycle length; it does not explain what 'limit' means, how 'interval' relates to the K-line fetch, or what constraints affect the output series. The parameter semantics are far from fully covered.

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 the tool's action and resource: pulling K-lines and calculating a simple moving average. It also mentions the return value ('稳定 SMA 序列') and the meaning of period. This sharply distinguishes indicator_sma from siblings like indicator_ema, indicator_rsi, or indicator_macd.

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 implies usage: when a simple moving average over K-lines is needed, this tool should be used. However, it provides no explicit when/when-not guidance or alternatives, and the term '直连版' hints at a particular mode without fully explaining it.

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

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

Annotations already mark it readOnly and openWorld, and the description adds that it computes from pulled K-line data and returns a K/D/J sequence. It does not cover failures or odd-specific shape, but the readOnly annotation reduces the need for mutation/risk disclosure.

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?

A single, front-loaded sentence that states the input action, the output format, and the tunable parameters with minimal filler.

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 output schema and read-only annotations exist, the definition is almost sufficient for simple invocation. However, the kSmoothing/kSlowing mismatch and lack of usage context leave a meaningful gap in advisory quality.

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 description tries to add parameter meaning by listing kPeriod/kSmoothing/dPeriod as adjustable, but the schema only contains kSlowing, not kSmoothing, so an agent could generate an invalid parameter. Since schema description coverage is 0% and limit/symbol/interval meanings are left unstated, the description does not fully compensate for the schema gap.

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 it pulls candlesticks and computes a KDJ stochastic indicator, returning a K/D/J triple series. This specific output distinguishes it from generic 'indicator_*' siblings.

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?

No guidance is given on when to choose KDJ versus the many sibling indicator tools, and no exclusions or alternative conditions are stated. '直连版' hints at a variant but does not explain when to use it.

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

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

注解已声明 readOnlyHint=true，描述补充了“拉取 K 线后计算”和“返回稳定序列”，这增加了对于工具行为的理解。但没有对数据源、稳定序列的含义或限制、是否依赖历史K线等做进一步披露。

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?

描述只有两句话，并且把主要行为、返回内容放在第一句，参数说明放在第二句，无冗余信息，阅读成本低。

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?

有输出 schema 作为补充，描述已覆盖算法来源和返回形态，但缺少 limit 的含义、直连版本的适用场景以及与其他 indicator 类工具的区分。对于一个需要 5 个参数的工具而言，本描述的信息仍不够完整。

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?

描述补充了 period 为 ATR 周期、multiplier 为通道倍数的语义，这两个定义是 schema 中缺失的。但它没有描述 symbol、interval、limit 的确切含义做到，另外定义不够完整；至少覆盖了部分核心参数。

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?

描述明确说明“直连版”是拉取 K 线线后后计算 SuperTrend 并返回“supertrend 值 + BULLISH/BEARISH 方向”，给出了具体动词、资源和输出形态，能够清晰区分。

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?

描描述没有说明在什么场景下优选此工具、何时应使用其他替代工具，也没有给出排除条件。虽然提到“直连版”，但这并不能让 agent 清楚它与其它 indicator 类工具的分工

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

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

Annotations already provide readOnlyHint=true and openWorldHint=true, so the description only needs to supplement actual behavior. It adds the algorithm source (Bollinger bandwidth percentile) and output categories, which give useful transparency. It still omits minor behavioral details such as what happens with insufficient data or whether the output is a series or single-of-state, though output schema metrics may cover some of this.

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 a compact one-liner that carries the formula, categories, and intended purpose without redundant wording. The qualifier '直连版' is slightly unexplained but does not bloat the sentence. It is near-ideal in size and accessibility.

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?

An output schema exists, so the return-value description is not strictly needed. The formula, output states, and position-management purpose give the core context, but the absence of sibling-tool routing and full parameter population left the agent somewhat limited when disambiguating this tool, from Bandwidth and ATR or setting the right limit.

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 only 20% since only, lookback has a schema description. The description indirectly connotes meaning for bbPeriod and lookback via '布林带宽百分位', but it does not expressly name or explain all parameters like limit, symbol, or interval. It partially compensates for the missing schema documentation, so semantics are clearer than a bare param-list but still incomplete.

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 states a clear verb-based role: it classifies volatility regimes from Bollinger bandwidth percentile and enumerates the five output states (squeeze, low_volatility, normal, high_volatility, expansion). This makes the tool functional-purpose obvious, though it does not explicitly contrast with sibling volatility indicators such as bbands or ATR.

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 phrase '辅助仓位管理' provides a plausible use context (position sizing decisions). However, it does not say when to choose this over alternations like indicator_bbands or indicator_atr, nor defines exclusion conditions or setup prerequisites. The use case is inferred, not explicitly routed.

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

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

The annotations already mark the tool readOnlyHint/openWorldHint, and the description adds useful behavior beyond that: it fetches K-lines, computes a cumulative rather than rolling VWAP, and returns a stable sequence. This gives real insight into the computation model without contradicting the annotations.

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?

One short sentence with no filler. The core mechanism is front-loaded ('直连版') and the computation objective is stated directly, making the description easy to process.

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?

For a simple read-only indicator with only three parameters and an output schema, the description is nearly sufficient for calling the tool. However, the vague '直连版' term and the absence of parameter and usage context leave some room for an agent to mis-model when and how to invoke it.

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%, and the description does not compensate by explaining symbol, interval, or limit. It only implies K-line context, so the agent must rely entirely on the property names and enum values without any descriptive clarification.

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 states a clear action and resource: pull K-lines, compute cumulative VWAP, and return a series. It clearly distinguishes this from trading tools, but it does not explicitly contrast it with the sibling indicator tools such as indicator_sma or indicator_ema. The overall purpose is clear even without sidder differentiation.

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?

There is no guidance about when to use VWAP relative to other indicators, or which conditions favor this '直连版' over any alternative. '直连版' hints that another version may exist, but no alternative, tradeoff, or exclusion is described.

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

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

annotations 已声明 readOnlyHint 和 openWorldHint，描述在此基础上补充了全市场调用成本高的风险提示，对 agent 实际调用有实质价值。未提限频、返回体量等，但已有注解覆盖安全性，这仍高于基本要求。

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?

整个描述一句话完成，主行为在前，调用警告在后，没有重复 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?

对单参数、有安全注解、无输出 schema 的工具来说，已交代用途、返回维度、缺省行为和高成本风险。缺少数显式替代条件与 symbol 格式示例，但对于这类简单只读行情工具已达到足够完整度。

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 仅有一个可选的 symbol，且描述覆盖率为 0；描述明确说明缺省 symbol 时的语义是会返回全市场并带来高 weight，这超出 schema 本身的信息。虽然没有给出 symbol 写法示例，但 symbol 为自明性参数，可选行为已经落实清楚。

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?

描述以具体动词“获取”指明行为，“24h 滚动统计（涨跌幅/高低价/成交量额）”明确资源类别，并与 market_price、market_book_ticker 这类实时快照工具区分。缺省 symbol 返回全市场这一行为也进一步明确了工具边界。

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?

描述了缺省 symbol 时返回全市场，并明确提示 weight 高、慎用，这是清晰的调用条件。虽然没有显式列举可替代工具，但已提供了决定“带 symbol 还是不带”的直接指导。

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

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

With readOnlyHint and openWorldHint already declared safe, the description adds real behavioral value by noting that omitting symbol changes the scope to the entire market and increases API weight. This is beyond both the schema and annotations and helps the agent avoid an expensive accidental call.

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?

Two parenthetical-clauses, each crucial: no inherited wasted. The core return value is front-loaded, the weight caveat at the end is essential. Every sentence earns its place.

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?

For a low-complexity light market data tool with no output schema, the description fully enough: what it returns, that it is lighter than the orderbook, and the scope/weight implication of the default. The agent can select and call it confidently without missing unknown consequences.

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 schema description coverage is 0%, but the description compensatesru: 'symbol' semantics by explaining that omitting symbol returns the whole market, and 'weight high, use with caution'. The only param is self-evidently a market ticker symbol, so absentity of format examples is a meaning gap but not a serious one.

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 states in Chinese that this retrieves the best bid/ask price and quantity, which is a specific verb + resource. It also explicitly distinguishes it from the order book by calling it lighter, making it easy to tell apart from market_orderbook and other market data tools.

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 selection context: use it when you need top-of-book prices, and it contrasts with the full order book. It also warns that omitting symbol returns the whole market with a high weight, so an agent knows when to be cautious. It stops short of naming an explicit alternative tool, but the intended contrast to the order book is evident.

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

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

The annotations already declare readOnlyHint and openWorldHint, covering the main safety and completeness expectations. The description adds no further behavioral detail about paging, limits, returned data shape, or differences across contract types, so it is adequate but not enriching.

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 a single concise, front-loaded sentence with no filler. Every word contributes to identifying the resource and scope.

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 has 4 parameters, no output schema, and no parameter documentation, the one-line description is insufficient for an agent to confidently call the tool in edge cases such as choosing between contract types or understanding limit behavior.

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 schema description coverage is 0%, so the description was expected to carry parameter meaning. It explains none of pair, limit, interval, or contractType beyond the overall concept of K线. The agent must rely entirely on parameter names and schema enums.

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 a specific resource ('连续合约…的K线'), with examples (季度/永续) that help disambiguate it from the more generic sibling market_klines. It does not explicitly name the sibling, so it stops short of full differentiation.

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 intended usage is implied: use this tool when continuous-contract candlestick data is needed. However, it does not explicitly say when not to use it, nor does it point to market_klines or another alternative.

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

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

Beyond readOnlyHint, the description discloses default all-market behavior, large payload risk, andespecific fields returned. It does not mention pagination or response shape, but the operation is a simple read-only info lookup and annotations already cover safety.

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?

Two concise clauses, front-loaded with the core purpose and fields, followed by a caution. Every sentence earns its place and there is no indentation or unrelated text.

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?

For a simple read-only exchange-information tool with one optional parameter and no output schema, the description covers the return content and the all-market cas. It does not mention exact output container/format, but the named fields provide enough.

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 define symbol semantics. The description implies that symbol filters to a trading pair by saying 'default returns all market', but it never explicitly states the symbol format/value and does not explain what the parameter represents in relation to the output. It compensates partially but not fully for the empty schema.

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 specific verb+resource: obtain trading-pair precision specifications, and enumerates the returned fields (price/qty decimals, tickSize, stepSize, minnotional). This clearly distinguishes it from sibling market book/ticker/kline tools.

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?

It tells the agent that omitting symbol returns he entire market and warns that the payload is large and should be used carefully, which implies passing a symbol to limit scope. It could be stronger with an explicit 'use this when you need precision/exchange rules rather than market data or trading operations', 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.

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

Annotations already signal read-only and open-world, but the description goes beyond them by exposing a high-usage cost ('weight 高慎用') and the unparameterized global scope. It also clarifies that the output contains rules, not current values, which is a key operational distinction.

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 compact and front-loaded: it states the exact endpoint purpose, the returned fields, the no-filter scope, a usage-cost warning, and a sibling alternative. Every clause adds value, and there is no redundant prose.

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?

With no parameters and no output schema, the description nonetheless tells the agent what it will receive (rules for all currencies: upper/lower rate limits and settlement intervals) and how it differs from the current-pair tool. The agent can invoke the tool correctly without further documentation.

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 is empty, so there are no parameters to document. The description still adds meaning by making clear that symbol-level filtering is intentionally absent, preventing an agent from looking for a symbol parameter that does not exist.

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 the exact verb and resource: '获取全市场资金费率规则' and spells out what it returns (费率上下限与结算间隔). It also distinguishes itself from a sibling by noting that current single-pair funding values belong to market_mark_price, so the agent can tell tools apart without opining schemas.

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?

It states scope explicitly ('无 symbol 过滤') and warns the weight is high, so the caller should use it sparingly. It also gives a concrete alternative with a clear conditional: for a single trading pair's current funding rate, use market_mark_price.

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

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. The description adds that the result is a historical record of funding rates, but it does not disclose behaviors such as ordering, time range, what happens when no symbol is provided, or whether the rate is the latest vs. per-interval. No contradiction with annotations.

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 one clean, front-loaded sentence with zero filler. It states the exact action and resource without any redundant explanation, so it earns its place.

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?

While the tool is simple and has annotations protecting safety, the description does not clarify any alternative use case versus siblings, the meaning of `limit` in plain terms, or the expected behavior when `symbol` is omitted. For a two-parameter read-only tool, this is minimally acceptable but leaves some gaps an agent would have to infer from the schema.

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 for parameter meaning. It partially clarifies that 'symbol' refers to a trading pair via '指定交易对', but it says nothing about `limit` other than what the schema fields already provide (default, min, max). The description does not explain the meaning of the records returned or how the limit affects them.

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 states a specific verb ('获取' / get) and resource ('指定交易对的历史资金费率记录' / historical funding rate records for a specified trading pair). Using '历史' clearly distinguishes this from the sibling `market_funding_rate`, making its purpose unambiguous.

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 no explicit when-to-use or when-not-to-use guidance and does not mention alternatives like `market_funding_rate` or `market_mark_price`. The only implicit signal is the word '历史' (historical), which the agent must infer means this tool is for past data rather than current funding rate.

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

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

The annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds context about the return content (OHLCV and trade info) and time-range support, but does not disclose pagination, ordering, or any other parser-specific behavior. Acceptable but not rich.

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 a single concise sentence in Chinese that front-loads the main operation ('获取指定交易器与周期的 K 线') and adds useful detail (OHLCV, volume, time range). Every part contributes value; there is no haffle.

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 tool is a simple read-only data retrieval operation, and annotations already cover its read-only nature. The description states the object, key parameters, and time-range filtering; with an output schema present, it does not need to explain return structure. Minor absence of limit/> pagination and clear sibling distinction leaves it 1 point short of complete.

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?

With schema coverage at 0%, the description carries most param burden. It clarifies that `symbol` means trading pair and `interval` means period, and that `startTime`/`endTime` form a range filter. However, `limit` is never mentioned, and the schema has no per-parameter descriptions, so some parameter semantics still rely on type names/defaults.

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 the verb '获取' and the resource 'K线' with specific scope (trading pair and cycle) and content (OHLCV plus volume/trade info). It does not explicitly distinguish itself from the sibling `market_continuous_klines`, so it falls short of a 5.

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 no guidance on when to use this tool versus alternatives like `market_continuous_klines` or `market_price`. It only mentions an available feature (time-range filtering), without stating prerequisites, exclusions, or alternative conditions.

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

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. The description adds meaningful behavioral context around default behavior (omitting symbol returns full market) and the high weight cost, which is useful for an agent deciding whether to invoke the tool.

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 short and well-structured: the main resource is stated first, the preferred use case is next, and a caution about default behavior closes it. Every sentence earns its place with no redundant content.

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 a single optional parameter, read-only annotations, and no output schema, the description covers the essential invocation-relevant details. It lacks an explicit symbol format example, but the caution about missing symbol and the funding-rate fields named make it sufficiently complete for an agent to select and call the tool correctly.

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 schema only defines an optional string symbol with no description, so the description carries the parameter-semantics burden. It explains that symbol targets a single trading pair and that omitting it means full-market data, which adds real meaning; however, it does not specify the expected symbol format.

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 states a specific verb and resource: it fetches mark price, index price, and funding rate information. It also differentiates itself by calling out the single-trading-pair funding rate values use case, which helps an agent distinguish it from related market tools.

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 usage context: use this tool first when querying a single trading pair's funding rate values, and warns that omitting symbol returns the whole market with high weight. It does not explicitly name a specific sibling alternative, but the '首选本工具' guidance makes the intended use case clear.

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

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

The annotations already mark this as readOnlyHint=true, and the description adds that the result is 'current' and scoped to a pair. It does not mention freshness, rate limits, or behavior on invalid symbol, but for a read-only snapshot that gap is acceptable.

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?

One single sentence with no redundant words or filler. The important resource and scope are front-loaded.

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?

For a one-parameter read-only tool with an output schema and annotations covering safety, the description is nearly sufficient. The only remaining gap is the exact symbol format and possibly supported contract type, but those are minor for a simple 'get by symbol' tool.

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 schema supplies a bare 'symbol' string with no description and 0% schema description coverage. The description clarifies that symbol means '交易对', but it does not define the expected format, casing, or exchange convention, so the parameter semantics is only partially compensated.

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 object: it '获取' the '当前未平仓量' for a given trading pair. This clearly distinguishes the resource from market_price, market_funding_rate, and other sibling tools, but it does not explicitly name any sibling or contrast itself.

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?

Description does not explicitly provide when to use or when not to use this tool. The intended usage is inferred because the resource is open interest; however, with 50+ sibling tools in the market domain, no explicit guidance is given for selecting this one over a more general market tool.

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

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

The annotations readOnlyHint=true and openWorldHint=true already convey the read-only, potentially changing nature of the data, and the description does not contradict them. The description adds meaningful behavioral guidance beyond the annotations by constraining limit to legal values (5/10/20/50/100/500/1000), which the schema leaves effectively unbounded. It does not describe the ordering of the bid/ask sides, a minor gap for a read-only snapshot tool.

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 compact: one clause establishes the action, one clause delivers the parameter constraint. Every sentence earns its place, and the most decision-relevant information (legal limit values) is front-loaded immediately after the purpose.

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 two simple parameters, a read-only and open-world annotation set, and no output schema, the description covers what the agent needs in order to invoke the tool correctly: the supported symbol and the admissible limit values. A short note on return shape (e.g., sides/ordering) would be a nice addition since no output schema exists, but it is not blocking for a basic snapshot call.

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?

At 0% schema description coverage, the description compensates well: the phrase '指定交易对' explains what the symbol parameter means, and the explict enumeration of legal limit values (5/10/20/50/100/500/1000) provides far more precision than the schema's meaningless numeric bounds. It does not explain whether the limit applies to each side or the total depth, but the core meaning of both parameters is in place.

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 a specific action and resource: '获取指定交易对的买卖盘快照' (fetches a snapshot of the order book for a specified trading pair). It is unambiguous about which resource it concerns, though it does not explicitly contrast itself with the similarly named sibling market_book_ticker.

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?

There is no when-to-use or when-not-to-use guidance. The description never explains why an agent should choose this tool instead of market_book_ticker (best bid/ask) or market_klines (candles); an agent is left to infer the use case from the tool name and purpose alone.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that the tool aggregates many analysis dimensions in one call, which is useful behavioral context. It does not disclose how `limit` and `interval` shape the returned snapshot, nor any timing or completeness caveats, though the schema and annotations reduce the burden.

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 one efficient sentence: it front-loads the single-call behavior, defines the scope as one trading pair, lists the major analysis categories, and states the intended downstream use. There is no filler, repetition, or redundant restatement of the tool name.

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 read-only annotation, the existence of an output schema, and only one required parameter, the description is almost sufficient for an agent to call the tool. The main missing piece is the semantics of `interval` and `limit`, since the description does not clarify whether they affect the analysis window, sample size, or underlying data aggregation.

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 should compensate. It adds meaning for `symbol` ('single trading pair'), but it does not explain what `interval` or `limit` mean in the context of a market overview, nor how defaults and bounds affect the result. The parameter names and schema constraints are only partially self-explanatory.

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 states a clear verb and resource: it returns a complete analysis snapshot for one trading pair in a single call, covering market, liquidity, funds, sentiment, indicators, and derived values. It is clearly meant for direct AI interpretation and conclusion generation. It does not explicitly contrast itself with individual sibling tools, but the aggregate-scope is distinctive enough.

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 clearly indicates its intended use: when an AI needs a comprehensive single-pair overview in one shot and will interpret the results directly. It also restricts scope to a single trading pair. However, it does not explicitly name alternative tools or describe when not to use it in favor of a specific market/indicator endpoint.

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

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

The annotations already indicate read-only and open-world behavior, and the description reinforces that by stating the tool only tests connectivity and returns a simple success object. It also discloses the expected success response, which adds value beyond the annotations. It does not describe failure behavior, but that is a minor omission for a ping tool.

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 a single concise sentence that front-loads the purpose, mentions the lack of parameters, and states the expected return value. Every word adds information, with no redundancy or filler.

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?

For a simple no-parameter connectivity test with an output schema and readOnly annotations, the description provides all necessary information: what it tests, that no parameters are needed, and what a successful result looks like. Nothing required for an agent to select and invoke this tool is missing.

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?

There are zero parameters, and the description explicitly states 'no parameters required,' which removes any ambiguity. The baseline for zero parameters is 4, and the description fully confirms this without needing extra param details.

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 states a specific action (testing connectivity) and a specific resource (Binance exchange REST API), and clearly differentiates itself from sibling market data tools by focusing on connectivity rather than data retrieval. It is not a tautology and adds detail beyond the tool name.

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 clearly conveys that this tool is used for a connectivity check and explicitly notes that no parameters are required. It does not name alternative tools or specify when not to use it, so it falls short of the 'explicit when/when-not' bar, but the use case is obvious and unambiguous.

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

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

注解已经声明 readOnlyHint 和 openWorldHint，因此安全性和网络属性已覆盖。描述补充了返回值字段 symbol 和 price（number 类型），但未说明数据时效性、缓存或异常行为；对这类简单查询可接受。

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?

描述仅两句，第一句即点明核心动作和对象，第二句说明返回值，信息密度高且无冗余。结构十分简洁高效。

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?

工具本身只有一个参数，且存在输出 schema，返回结构不必由描述完整展开。整体说明足够支撑调用，但缺少 symbol 写法和命名惯例，因此略距“完全完整”一步。

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 覆盖率为 0%，描述必须承担参数语义。描述中“交易对”暗示 symbol 代表交易对，但没有说明 symbol 的具体格式（如 BTCUSDT 还是 BTC/USDT），也没有任何约束说明。描述未能充分弥补缺少参数文档的问题。

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?

描述明确指定了动作和资源：获取指定交易对的最新成交价。成交价一词能与同类的 market_mark_price、market_24hr_ticker 等工具自然区分，但没有显式点出替代工具，因此略低于最高分。

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?

描述没有说明何时应使用本工具而不使用其他市场数据工具，也没有排除性说明，例如不需要深度数据时使用 market_price、需要标记价格时使用 market_mark_price 等。使用场景只是隐含在名称和描述中。

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

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

The readOnlyHint annotation already tells the AI the operation is safe and non-mutating. The description adds the precise return type and use-case context, which is useful but modest.

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?

One precise sentence with no filler: it states what is returned, the unit, and the intended purposes. Every phrase carries information.

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?

For a zero-parameter, read-only, server-time tool with an output schema present, the description is complete. An agent knows exactly what to expect and how to use the result.

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?

There are no parameters, and the schema describes this fully with 100% coverage. A clear description is still helpful to mention what the tool actually retrieves.

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 states a specific verb and resource: it fetches Binance server time as a millisecond timestamp. This clearly distinguishes it from sibling trading and market-data tools.

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?

It explicitly gives usage context: clock synchronization and signature verification. It does not name alternatives or exclusion cases, but with zero parameters and a unique purpose, the given context is sufficient.

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

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

Annotations (readOnlyHint, idempotentHint, openWorldHint) already cover the safety profile, so the description's burden is low. It adds one useful fact: the response is an aggregated 汇总 of wallet/UP/L/margin. It does not reveal whether the numbers are real-time, cached, or aggregated across all account assets, but for a simple read-only overview the output schema likely covers that - the description also completes the annotations without any attribution.

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?

One short sentence, front-valued verb and enumerated result categories, and no fluff. The Chinese phrasing is compact and precise; every element earns its line space. Even the title and description together leave no repetition.

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?

For a zero-parameter, read-only, idempotent tool with an output schema, this definition is nearly complete: an agent can sed it and understand what should come back (the summary categories), since schema/annotations cover the rest. The one missing piece is an explicit relation to sibling trading_balance to prevent picking the wrong account tool, but given the tool's low complexity, this is a small omission.

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 tool admits zero parameters, so the baseline for parameter semantics is 4; there is nothing the description needs to document. The field list (wallet balance, unrealized P&L, margin) tellingly shapes the no-arg call's result, which is all the param-aware an agent can ask given an empty schema.

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 states a specific verb ('返回' - returns) plus the resource: wallet balance, unrealized P&L, margin summaries. It clearly conveys an account-overview aggregation, reinforced by the title 账户总览. It does not explicitly distinguish itself from sibling tools such as trading_balance, so it falls a step short of 5.

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?

There is no guidance on when to invoke this tool versus alternatives, and with dozens of trading siblings including trading_balance, trading_positions, trading_position_mode, and trading_position_margin, an agent gets no routing hint because it is a summary-use it. The 'when-to-use' must be completely inferred, so this is effectively implied-only minimal formulation.

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

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

The annotations already cover read-only, idempotent, and open-world behavior, so the safety profile is clear. The description adds the scoping detail that only current un-triggered conditional orders are returned, but it does not mention pagination, output shape, or what happens when symbol is omitted. No contradiction with annotations exists.

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 short sentences, front-loads the return purpose, and contains no filler. It is appropriately compact, though its terseness is part of why some semantic and routing details are missing.

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?

For a read-only list endpoint with one optional parameter and no output schema, the description covers the essential contract: what is returned, that the orders are current and un-triggered, and that symbol can be used. Pagination or response shape details would be nice, but are not critical for making the call correctly.

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%, and the description only says 'symbol 可选'. This conveys that symbol is optional, but it does not explain the symbol format, whether omitting it returns all symbols, or whether it functions as an exact filter. For a one-parameter tool this is workable, but the description does not fully compensate for the empty schema.

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 states the specific operation: return currently pending, un-triggered conditional orders. The qualifier '条件单/未触发' clearly distinguishes this from related order endpoints like trading_open_orders, trading_order_history, and trading_get_order.

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 clearly identifies the intended context: retrieving current conditional orders, with symbol as an optional filter. It does not explicitly say when not to use it or which sibling endpoint to choose for regular open orders, historical orders, or single-order lookups, so the routing guidance is only implied.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral scope by specifying '全部资产余额' and including unrealized P&L, with no contradiction to the annotations.

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?

One short sentence with no filler. The key information is front-loaded, and every part of the description earns its place.

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?

For a parameterless read-only tool with an output schema and safety annotations already provided, the description is complete. It states exactly what is returned and that unrealized P&L is included, leaving no invoke-time ambiguity.

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 zero parameters and 100% schema description coverage, so no parameter details are needed from the description. The baseline 4 applies because there are no parameters whose meaning could be ambiguous.

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 specifies a verb (返回) and a clear resource (账户全部资产余额), and further clarifies the return content with 含未实现盈亏. This distinguishes it from related siblings like trading_positions and trading_account, even without explicitly naming them.

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 intended use is implied by the tool name and description: any time an agent needs the account's full asset balance including unrealized P&L. However, there is no explicit guidance or exclusion pointing to alternatives such as trading_positions or trading_account.

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

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

The description adds no behavioral detail beyond what annotations already convey: readOnlyHint is false and destructiveHint is true. It does not mention irreversibility, what happens on success/failure, or any side effects after the cancel request. The description is consistent with the annotations, so there is no contradiction.

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 a single sentence that front-loads the purpose and then adds the key parameter constraint with no redundant filler. Every part earns its place.

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?

For a two-parameter destructive tool and no output schema, the description captures the essential: cancel the conditional order and provide one of two identifiers. However, it lacks guidance on behavior for invalid identifiers, both-or-neither ID cases, and possible response behavior, so the invocation context is only minimally complete.

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?

With 0% schema description coverage, the description must compensate. It adds the crucial one-of relationship ('clientAlgoId 与 algoId 二选一'), which is not visible in the input schema. However, it does not define what each ID represents or how they differ, leaving partial semantic burden on the parameter names alone.

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 explicitly states the action ('撤销条件单' = cancel conditional order), naming the resource type as conditional/algorithmic orders. This clearly differentiates it from regular order cancellation tools like trading_cancel_order, but it does not explicitly named-and-distinguish sibling tools.

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 only gives the parameter constraint that clientAlgoId and algoId are mutually alternative; it does not say when to use this tool rather than trading_cancel_all or trading_cancel_order, nor what to do if the order was already filled or does not exist. There is essentially no play/sibling guidance.

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

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

Annotations 已声明 destructiveHint=true、readOnlyHint=false，而描述进一步明确了破坏范围为“指定交易对的全部未成交订单”，补充了操作规模和对象。描述与 annotations 一致，无矛盾。

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?

整个描述只有一句简短完整的中文，信息密度高，没有冗余内容，也没有重复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?

作为销毁性操作，描述说明了取消范围和对象，但缺少 symbol 格式约束、取消后的返回行为，以及是否对已提交未成交的算法订单生效等上下文。由于没有输出 schema，描述本身并未完整覆盖调用者可能需要的全部行为信息。

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 只有一个 symbol 参数且无任何说明，schema 描述覆盖率为 0%。描述中的“指定交易对”为 symbol 参数提供了基础语义，但未说明 symbol 的具体数值格式（如 BTCUSDT 还是 BTC/USDT），也没有给出示例，因此补偿有限。

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?

描述包含明确动词“撤销”、目标资源“全部未成交订单”以及作用范围“指定交易对”，清晰说明工具功能。它与同组工具 trading_cancel_order（撤销单个订单）和 trading_cancel_algo（撤销算法订单）在语义上可区分。

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?

描述隐含了使用场景：需要撤销某个交易对的全部未成交订单时使用。但没有明确说明在单笔撤单时应改用 trading_cancel_order，也没有给出任何“何时不要使用”或替代工具的排除说明，属于隐含而非显式指导。

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

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

The annotations already provide destructiveHint=true and readOnlyHint=false, covering the mutating nature. The description states the action (cancel) and the scope (specified order) but does not disclose additional behavioral traits such as idempotency, failure conditions for already-filled orders, or whether the order is removed permanently. It adds marginal scope context beyond the annotations, warranting a median score.

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 one short sentence that front-loads the primary action and then adds the critical identifier-choice constraint. It avoids fluff, every clause earns its place, though it is terse rather than comprehensive.

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 tool has 3 parameters, no output schema, and only a sparse description. It communicates the core action and the key identifier constraint, but omits details such as when cancellation might fail, the need to specify symbol alongside the chosen ID, and any confirmation behavior. This is acceptable but not fully complete for an agent to understand all edge cases.

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 schema has 0% description coverage, so the description must clarify parameters. It does this effectively by stating "orderId 与 origClientOrderId 二选一" — indicating the two identifiers are mutually exclusive alternatives (pick one). This is essential information absent from the JSON schema, but it still does not explain the symbol parameter's role, which remains minimal.

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 begins with a specific verb+resource pair: "撤销指定订单" (cancel the specified order). The word "指定" (specified) directly distinguishes it from the sibling tool trading_cancel_all, which cancels all orders, so the agent knows which tool is relevant for a targeted cancellation.

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 implies usage: cancel one specific order identified by orderId or origClientOrderId. It does not explicitly state when to avoid this tool (e.g., when wanting to cancel all orders, use trading_cancel_all) nor mention any preconditions like the symbol being required. It provides a parameter-choice guideline but no broader usage context.

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

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

The annotations already declare readOnly, idempotent, and openWorld behavior, so the description does not need to restate safety. It does add useful context about the inclusion of VIP discounts and BNB deduction in the returned rate, which goes beyond the annotations and clarifies rate semantics.

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 a single sentence with a clear front-loaded action and the key scope immediately after it. It contains no filler, redundant phrasing, or repetition of schema or annotation details, earning its place efficiently.

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?

This is a simple single-parameter read-only tool, and the description plus the available output schema are sufficient to guide a caller. The only minor gap is that the exact expected symbol format is not specified in the description, but the schema field name and simple shape keep the completeness high.

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 schema has no description for the 'symbol' parameter, and schema coverage is 0%. The description compensates by identifying the parameter as the '指定交易对' (specified trading pair), which directly maps to 'symbol'. This gives essential meaning even if it does not specify the exact string format like 'BTCUSDT'.

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 states a specific verb ('返回') and a precise resource: maker/taker rates for a specified trading pair. It also adds detail about VIP discounts and BNB deduction, making it distinct from any market or position-focused sibling tools. There is no ambiguity about what this tool returns.

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 implies usage: call it to retrieve fee rates for a given trading pair. It does not explicitly discuss when to prefer this tool over alternatives, but no sibling has a similarly direct fee-return purpose, so the context is reasonably inferable. The absence of explicit exclusions or alternative routing keeps it at a mid score.

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

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

The provided annotations readOnlyHint/idempotentHint already cover the safety profile, and the description adds that the returned records are specifically force-liquidation/ADL. However, it discloses no additional behavioral details like pagination limits, what populates the 'ADL' vs 'DIQUIDATION' subtypes, or open-world behavior beyond the annotations.

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 a single, front-loaded sentence that wastes no words and immediately conveys the core return type. It is appropriately compact, though the compactness comes at the expense of the other information an agent needs.

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?

With no output schema, no parameter descriptions, and no usage notes, the description is too thin to be considered complete. An agent cannot know how to safely or usefully set 'limit', 'symbol', or 'autoCloseType' from the description alone, nor what fields the returned record list will contain.

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?

There are 3 parameters, schema description coverage is 0%, and the description does not mention any of them. Plot, autoCloseType, or how filtering works. The schema namesand enum are self-evident to some degree, but the description provides no extra semantic guidance, so it completely fails to compensate for the absence of property descriptions.

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 a precise resource ('强平/自动减仓（ADL）订单记录'), making the tool's purpose clear. It also inherently distinguishes this from general order-history tools, though it does not explicitly name a 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 gives no context on when to prefer this over alternatives such as trading_order_history or trading_trades. There is neither an explicit 'when to use' statement nor any comparison with sibling tools.

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

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

注解已提供readOnlyHint=true、openWorldHint=true、idempotentHint=true，安全形态已被覆盖。描述补充了“orderId与origClientOrderId二选一”这一约束，但对获取行为、错误、返回格式等没有额外披露。未与注解矛盾。

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?

描述简洁紧凑，两句信息包含“返回结果”和“参数约束”，没有任何冗余内容。虽然可以更规范地改为一个完整句子，但在对效率和切题性上表现良好。

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?

对于工具的简单参数集合、该描述可一定程度上调用，但缺少“要查询的具体订单需要已知ID”这种应用场景提示，也没有提及返回值的形状或选型或许会因参数不同而异。它仍是“最小可用”而不算完整。

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?

模式描述覆盖率为0%，描述承担了部分参数解释：“orderId与origClientOrderId二选一”给出了两个参数的互斥选择关系，这对正确调用很关键。但未说明symbol参数、orderId的取值范围语义或origClientOrderId的格式，未完全弥补schema的空白。

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?

描述以明确的动词“返回”加资源“指定订单详情”表明这是按订单ID查询订单详情的工具。通过“指定订单”与“orderId/origClientOrderId”可以看出它与其他订单列表类工具（open_orders/order_history）区分，虽然未明确点名兄弟工具。

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?

描述没有说明何时使用此工具而不是trading_open_orders、trading_order_orders等替代方案。除“二选一”的参数约束外，没有给出明确的使用场景、前置条件或排除条件。

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds meaningful context (income negative means expenditure, incomeType consistent with official enum), but does not disclose pagination, ordering, time-range behavior, or response structure, so it is adequate rather than rich.

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?

Two short sentences front-load the core return value, followed by the key convention about negative income and incomeType enum. There is no filler, though a bit more structure around parameters would improve completeness.

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?

With no output schema, the description should explain what fields each record contains, but it does not. Parameter semantics are incomplete for 5 optional params, and time range behavior is not explained. In a large sibling family, these gaps make the definition only minimally sufficient.

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 carry the burden for explaining parameters. It only clarifies incomeType via examples and the 'official enum' note. It does not explain limit semantics, symbol format, or startTime/endTime units/format, and schema itself lacks descriptions, leaving agents to guess.

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 states a specific verb ('返回') and resource ('流水记录' of funding fee, commission, realized PnL), so an agent can identify it as an income/expense history tool. It does not explicitly differentiate it from trading_commission, trading_trades, or trading_account, so it falls short of a 5.

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?

No guidance is given about when to use this tool instead of alternatives like trading_commission or trading_trades. The intended use is only implied by the examples of income types, so agents browsing many siblings get little routing help.

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

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

Annotations already signal destructive behavior, and the description adds useful constraints: only unfilled orders and only LIMIT type are elligate for modification. It does not disclose deeper behavior such as whether existing order is replaced/caneled or how failures handled, but it meaningfully extends the annotations.

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?

One sentence delivers the essential scope and constraint without filler. The key function and the orderId/origClientOrderId exclusivity are front-loaded, making the definition easy and fast to parse.

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?

For a mutation tool with no output schema and no parameter descriptions, the definition is incomplete. It does not describe what happens after a successful modification, whether it replaces or cancels, possible failures, or how to know which side of the order to adjust. An agent would need substantial inferred knowledge to call it correctly.

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 schema description covers 0% of parameters, so the description must compensate. It clarifies that orderId and origClientOrderId are mutually exclusive, but it does not explain the meaning of symbol, side, quantity, or price beyond their raw schema names and constraints. This leaves significant semantics implied.

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 states a specific action ('modify unfilled orders') and an explicit scope restriction ('LIMIT only'). This clearly distinguishes the tool from place/cancel/get sibling tools and tells an agent exactly what resource it affects.

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 implies when to use the tool by restricting modifications to unfilled LIMIT orders, but it provides no explicit guidance about when to prefer this tool over trading_place_order, trading_cancel_order, or other alternatives. The scope is helpful but limited.

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

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

Annotations already provide readOnlyHint and idempotentHint, and the description adds the contextual scope (all current unfilled orders, optional symbol). There is no contradiction with annotations, but the description does not cover additional behavior such as pagination, market affects, or response structure.

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 very short sentences with no fluff. Core operation and param optionality are front-loaded. Every word adds necessary content.

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?

For simple a simple read-only tool with only one optional parameter, the core capability is communicated. However, with schema coverage at 0 and no output schema, the description leaves the agent with very little context about acceptable symbol values or how results are returned; enough for basic usage but not fully complete.

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 schema has only one parameter with no descriptions; the description merely says 'symbol 可选' and does not explain that the symbol filters the returned open orders or what format/values are expected. This is valuable only minimal information beyond the schema's optionality.

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 returns all current unfilled orders ('当前全部未成交订单') and notes the optional symbol parameter. This is specific and useful, though it does not explicitly differentiate itself from sibling order-related tools such as trading_order_history or trading_get_order.

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 no explicit when-to-use guidance or alternatives. The word '当前' hints that this is for current open orders rather than historical ones, but it does not tell the agent when to choose this tool over other trading order tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety profile. The description adds that results are returned in reverse chronological order, which is a useful behavior, but it does not disclose pagination, default limit behavior, or how the optional filters interact.

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 front-loaded and wastes no words: it tells what is returned, for which resource, and in what order, in a single efficient sentence.

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?

With five parameters and no output schema, the description is too thin to fully guide a correct call. It only establishes the required symbol and ordering, while filter parameters, default limit, pagination, and output format are not addressed.

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%, and the tool description only refers to the symbol via 'specified trading pair'. startTime, endTime, limit, and orderId are not explained, leaving their filtering semantics and combination behavior to be guessed from schema names and constraints.

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 states a specific action ('returns') and resource ('historical orders') scoped to a specified trading pair, with order direction specified as time-descending. It does not explicitly contrast with sibling tools like trading_open_orders or trading_trades, but 'historical' conveys the core distinction.

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?

No guidance is provided about when to use this tool versus alternatives such as trading_open_orders, trading_trades, or trading_get_order. There are no concrete conditions or exclusions, so the agent must infer use case from the name alone.

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