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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys a destructive cancel action but does not state that both buy and sell sides are affected, that the operation is irreversible, or whether partial fills are impacted. For a mutation tool with zero annotation coverage, this is a significant gap.

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 action sentence followed by an Args list is efficient and front-loaded. No filler words. It could add one behavioral caveat, but as structured it wastes nothing.

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 tool with an output schema, the core purpose and parameter are covered. However, given it is a destructive bulk operation with no annotations, it should warn that it cancels all orders (both sides) and is irreversible. The description is adequate but leaves these safety-relevant traits unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the schema's symbol field has no description. The description compensates by explaining the parameter with format ('交易对') and a concrete example ('BTCUSDT-PERP.BINANCE'), which is meaningful value beyond the structured 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 action — cancel ALL open orders ('所有挂单') for a specified trading pair — using a clear verb and resource. The word '所有' (all) distinguishes it from the singular sibling cancel_order, though the Chinese text relies on the reader knowing the pair format.

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 use this tool versus cancel_order, modify_order, or when to avoid it. It does not state that this is the all-at-once variant, nor warn that it is inappropriate when only a single order needs cancellation. Usage context is entirely implied by the name.

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?

No annotations are provided, so the description bears full responsibility. It only states the action itself and doesn't disclose whether cancellation is irreversible, whether filled orders are rejected, or any permission/state prerequisites. The behavior is basic and obvious, but genuinely valuable context is missing.

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?

Extremely concise with zero wasted words. The action is front-loaded, and the Args block clearly maps parameters to their meanings. Every element 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, both required parameters are explained, and an output schema exists. However, without annotations and with no mention of edge cases (e.g., attempting to cancel an already-filled order), the definition is minimally adequate 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?

With schema description coverage at 0%, the description compensates by explaining both parameters: symbol includes a concrete example (BTCUSDT-PERP.BINANCE) and oid is identified as the order ID. This adds meaning beyond the bare string types in the 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 clearly states a specific action ('撤销一个挂单' = cancel one pending order) with a verb and resource. It differentiates from the sibling cancel_all_orders by specifying a single order, though it doesn't explicitly name that alternative.

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 use this tool versus alternatives like cancel_all_orders or modify_order. The intended use case (cancel one specific open order) is implied by the name and arguments, but not stated explicitly.

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?

No annotations are provided, so the description carries the full burden. It explicitly discloses that this tool executes real trades on the exchange, which is a critical behavioral trait. It also documents the reduce_only flag semantics and the price requirement for limit orders. It does not mention side effects like order lifecycle or potential partial fills, but the real-trade warning is the most important disclosure and is clearly stated.

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 with the most important warning (real trade). The parameter list is structured and each line is informative. It could be slightly more concise by removing the redundant 'Args:' header, but overall it is well-organized and 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?

Given the tool's complexity (6 params, real-money side effects) and the absence of annotations, the description covers the essential semantics: what the tool does, the risk, parameter meanings, and the price requirement. It does not describe the output schema, but an output schema exists, so that is not required. It could add more about order type behaviors (e.g., POST_ONLY implications), but the current level is adequate for safe 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. It does: it explains each parameter's meaning, provides examples for symbol, amount, and price, and clarifies that price is required for limit orders and that reduce_only defaults to False. It does not enumerate allowed values for side or type, but the examples (BUY/SELL, LIMIT/MARKET/POST_ONLY) are given in the description, which is valuable beyond the bare 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 clearly states this tool places real orders on an exchange, with an explicit warning that it executes real trades. It names the specific action (下单/place order) and the resource (exchange), and the sibling list makes it distinct from read-only tools like get_balance or get_ticker. The verb and resource are 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 provides clear context: it is for real trading and should be used cautiously. It does not explicitly name alternatives or when-not-to-use conditions, but the warning '请谨慎操作' (operate with caution) and the contrast with the many read-only sibling tools imply it is the write-action tool. It lacks explicit exclusions, but the context is sufficient for an agent to select it for order placement.

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 no annotations, the description carries the full burden. It transparently indicates a read operation and the 'configured accounts' scope, but it does not disclose aggregation behavior, pagination, whether zero balances are included, or any other non-obvious runtime 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 concise sentence with no filler. The core action and scope are front-loaded, and every word contributes to understanding the tool.

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 tool with an output schema, the description is largely complete: an agent knows what it retrieves and what scope to expect. It could be slightly richer by naming get_balance as the single-account alternative, but nothing is missing for 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?

The input schema has zero parameters, so there is no parameter documentation burden. The description's phrase 'all configured accounts' adds relevant context about what is being queried, satisfying the baseline for a no-parameter tool.

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 ('获取', get) and a specific resource ('所有已配置账户的余额', balances of all configured accounts). It clearly distinguishes itself from the sibling get_balance, which is the single-account counterpart.

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 scope 'all configured accounts' implies when to use this tool versus get_balance, but the description never explicitly states when to choose this tool or when to prefer the singular alternative. No exclusions or alternative routing are provided.

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?

No annotations are provided, so the description carries the behavioral burden. It indicates a read-only retrieval ('获取') and discloses the optional filter behavior. It does not explain what happens when exchange is omitted, whether all exchanges are included by default, or any pagination/error behavior, but the read-only nature is clear.

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: the core purpose comes first, followed by the optional parameter in a clean Args block. There is no wasted text or redundant schema 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 simple tool with one optional parameter and an output schema, the description is nearly complete. It gives the core purpose and parameter guidance; the only missing explicit detail is whether omitting exchange returns positions across all exchanges, though that is strongly implied by '所有持仓' and '可选'.

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%, but the description compensates well for the single parameter. It explains that exchange is optional, what it does (filter by exchange), and provides concrete examples ('binance / bybit / okx'), adding meaning beyond the raw 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 clear verb ('获取' / get), a specific resource ('所有持仓' / all positions), and an optional filtering dimension ('可按交易所过滤'). The 'all' scope differentiates it from the sibling get_position, which implies a single-position lookup.

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 this tool to retrieve all positions, optionally filtered by exchange. It does not explicitly contrast with get_position or state when to prefer one over the other, so the guidance is present but implicit.

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 no annotations, the description carries the full burden of behavioral disclosure. It conveys that this is a read-only balance lookup and identifies the scoping parameters, but it does not mention authentication needs, error behavior, or account-type constraints. This is a minor gap for a simple read tool, but still below the bar for strong transparency.

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 well-structured: a clear one-sentence purpose followed by concise parameter explanations. Every line is useful and there is no redundant 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 low-complexity, two-parameter balance query with an output schema, the description adequately covers purpose and parameters. The notable gap is the lack of routing guidance relative to sibling tools, but this is not severe given the simplicity of the operation.

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 provides no descriptions or enums, so the description must compensate. It does so by explaining both parameters and giving concrete examples like 'binance / bybit / okx' and 'USD_M_FUTURE_TESTNET / LINEAR', which adds real meaning beyond the bare schema fields.

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 clear verb '获取' (get) and a specific resource: the balance for a specified exchange/account type. It implicitly contrasts with the sibling get_all_balances by emphasizing '指定' (specified), but it does not explicitly name that sibling or draw the 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?

The description provides no explicit guidance on when to use this tool versus get_all_balances or get_position. The intended use is implied by the parameter names and the word '指定', but there is no when-to-use/when-not-to-use direction.

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?

There are no annotations, so the description must carry the behavioral burden. It does state what is returned (configured exchanges and their connection status), and '获取' implies a read operation. However, it does not explicitly disclose whether this is safe/read-only, whether connection status is live or cached, or whether any network calls are made.

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 with no filler. It conveys the exact resource and the specific aspects returned in under 15 words.

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 info tool with an output schema present, the description is complete enough. It identifies what the tool returns and the scope (configured exchanges and connection status), and no additional invocation details are needed.

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 has zero parameters and 100% schema description coverage (empty object), so there is no parameter ambiguity for the description to resolve. Baseline 4 applies because no parameters 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 uses a specific verb (获取) and names a clear resource: configured exchanges and their connection status. This distinguishes it from sibling tools like get_balance, get_symbols, and get_market_info, since it focuses on exchange connectivity rather than balances, instrument metadata, or market data.

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 resource described, but the description gives no explicit guidance on when to use this tool versus alternatives such as get_symbols or get_market_info. No exclusions, prerequisites, or alternative tool mentions are provided.

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 no annotations, the description carries the full behavioral disclosure burden. It does disclose two important traits: the data is cached and a prior subscription is required. It does not mention what happens if the subscription is missing, how stale the cache may be, or any rate-limit considerations, but the disclosed facts are genuinely useful.

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 extremely compact: one sentence plus an argument example. Every phrase earns its place—cache source, subscription prerequisite, and symbol format. There is 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 one-parameter cached-data getter with an output schema present, the description covers the core essentials: what the tool returns, where the data comes from, and the required precondition. Minor open questions like error behavior without a subscription or how recent the cached data is prevent a perfect score.

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 provides zero description for the single 'symbol' parameter (0% coverage). The description compensates by explaining that it is a trading pair and giving a concrete format example, 'BTCUSDT-PERP.BINANCE'. This adds meaningful value beyond the raw schema, though it could clarify allowed variations.

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 verb ('获取/get') and resource ('资金费率/funding rate'), and adds useful scoping by saying the data comes from cache. This distinguishes it from related siblings like get_mark_price or get_index_price, though it does not explicitly name those alternatives.

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 a clear prerequisite: the agent must pre-subscribe to funding_rate before calling this tool. However, it does not explain when to prefer this tool over sibling market-data tools or when not to use it, leaving the usage context only partially specified.

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 no annotations provided, the description must carry the full behavioral disclosure burden. It reveals that the price is cached and that pre-subscription is required, which is useful. However, it does not explain what happens if the agent has not subscribed, whether the cached value can be stale, or what failure/error behavior to expect.

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: one sentence for purpose, one for a critical prerequisite, and a parameter example. Every part earns its place without redundant phrasing or unnecessary detail.

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 single-parameter read tool, the description covers the core operation and prerequisite. However, it omits behavior when the subscription is missingtuple, which is a key operational context. Since an output schema exists, return-value explanation is less necessary, but the failure mode remains a notable gap.

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 provides no description for the 'symbol' parameter, so the description's clarification that it is a trading pair with the example 'BTCUSDT-PERP.BINANCE' adds meaningful guidance. This compensates well for the 0% schema coverage, though it could mention whether only perpetual symbols are supported.

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 and resource: '获取缓存中的指数价格' (get cached index price). It clearly identifies the operation, but it does not explicitly differentiate itself from sibling tools like get_mark_price or get_ticker, leaving some ambiguity about when the index price is the appropriate source.

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 one important usage prerequisite: '需要先预订阅 index_price' (must pre-subscribe to index_price first). However, it does not state when to use this tool versus alternatives such as get_mark_price, nor does it give any exclusions or alternative routing 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'REST 请求' (REST request) and does not mention safety, side effects, rate limits, authentication, or pagination behavior. As a read-only get operation, this is a minor gap, but the description offers no explicit behavioral context beyond the trivial protocol detail.

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 extremely concise: a single sentence summarizing the purpose followed by a clean parameter list. Every line serves a purpose with no redundancy or filler, and the key information is 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?

Given the tool's simplicity (3 params, 1 required), an output schema exists, and no annotations, the description covers the essential usage details. It provides parameter explanations and a default, but could add more context such as maximum limit or the exact format of the returned data, though the output schema likely covers the latter. Overall, it is adequate for an agent to invoke 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%, so the description must explain all parameters. It does so effectively: symbol with an example, interval with a list of common values, and limit with a default. This adds significant meaning beyond the bare schema types, though the interval list is not exhaustive (uses '等' for 'etc.').

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 retrieves historical K-line data (获取历史 K 线数据) with a specific verb and resource, and it explicitly mentions it is a REST request. This distinguishes it from siblings like get_ticker (current price) and get_orderbook, 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 implies usage for historical candle data but does not explicitly mention when to use it versus alternatives, nor does it list exclusions or alternative tools. The purpose is clear enough that an agent can infer when to call it, but no explicit routing guidance is provided.

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 no annotations, the description must disclose behavioral traits, but it only mentions the data scope ('精度、最小数量等' – precision, minimum quantity, etc.), giving some hint of the return content. It doesn't specify if data is current, if there are rate limits, or if any other behavior like caching applies. For a simple market info tool, this is adequate but not fully transparent.

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 very concise, consisting of a single sentence followed by a clear Args section with a parameter explanation and example. It is appropriately front-loaded with the main purpose and immediately provides the necessary context for the parameter, with no wasted words.

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?

Despite having no output schema, the description mentions the type of data returned (precision, minimum quantity, etc.), which partially covers return value expectations. The tool is relatively simple with one parameter, and the description gives enough for an agent to call it correctly, though it could benefit from listing what '等' includes to be fully complete. Given the tool's complexity, this is strong.

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 only declares the parameter 'symbol' as a string with no description. The description provides crucial meaning by explaining its format with an example (BTCUSDT-PERP.BINANCE). Given the schema coverage is 0%, the description fully compensates by defining the expected value, earning higher score.

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 purpose: '获取指定交易对的市场详情' (get market details for a specific trading pair), and specifies the resource (trading pair). The example symbol clarifies the input format. However, it doesn't explicitly differentiate from siblings like get_ticker or get_exchange_info, which it might overlap with.

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 you need market details for a specific symbol) but lacks explicit guidance on when to use this over alternatives. For instance, it doesn't mention when to choose get_exchange_info or get_ticker instead. No exclusions or alternative tool names are provided, making the selection less precise.

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 no annotations, the description carries the behavioral disclosure burden. It usefully reveals that the value is read from cache and depends on a prior subscription, but it does not specify failure behavior if the subscription is missing, staleness of the cache, or whether the call has side effects.

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 minimal and front-loaded: purpose, prerequisite, then parameter example. No sentences are wasted, and the critical subscription constraint appears 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?

For a one-parameter getter with an output schema available, the description covers purpose, prerequisite, and parameter meaning. It could be more complete by describing what happens when the subscription has not been made, but the tool is simple enough that this is a minor gap.

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 the bare `symbol` field. It does so by defining it as a trading pair and giving a concrete format example ('BTCUSDT-PERP.BINANCE'), which is sufficient for the single parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('get cached mark price') and identifies a distinct resource ('mark price') from sibling tools like get_index_price. The cache qualifier and pre-subscription note further differentiate it from direct market-data fetchers.

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 states the prerequisite that the agent must pre-subscribe to mark_price before calling, and characterizes the data as cached, which sets expectations for when it is appropriate. It does not name alternative tools or exclusions, so it stops short of a 5.

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 no annotations, the description carries the burden. It discloses the key behavioral constraint (must specify symbol or exchange) and that it returns all open orders. It does not mention precedence when both params are given, result limits, or whether this is account-wide, but for a read-style listing tool the essential behavior is stated.

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 efficient: one sentence states the operation and constraint, followed by concise parameter examples. No filler or repetition of schema metadata. The key requirement is 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?

Given that an output schema exists and the tool is a read-only listing, the description covers the operation, the required filter, and the argument formats. It lacks sibling differentiation and any mention of edge cases, but an agent has enough to invoke 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?

Schema coverage is 0%, so the description must compensate. It does so by naming each parameter, giving a concrete format example (BTCUSDT-PERP.BINANCE, binance), and stating the one-of requirement. This adds real meaning beyond the bare schema. A bit more format detail would push it higher.

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 — retrieving all open orders — with a clear resource and scope. The '所有挂单' (all open orders) wording distinguishes it from the sibling get_order, which presumably fetches a single order. The required filter condition is front-loaded.

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 clearly states a hard prerequisite: provide either symbol or exchange. However, it does not explicitly say when to use this tool versus the many sibling order/position tools, nor does it describe what happens when both or neither are provided. Usage is mostly implied by the tool name rather than explicitly guided.

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 no annotations, the description must carry the full behavioral disclosure burden. It only says 'get detailed information'; it does not explicitly state that the operation is read-only, has no side effects, or mention any authentication or rate-limit considerations.

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, front-loaded, and contains no filler. The Args line is useful because the schema lacks parameter descriptions, though the overall content is minimal.

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 and has an output schema, so return-value documentation is not necessary. However, the description omits usage boundaries and behavioral details that would help differentiate it from sibling order 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?

The schema only declares oid as a string with zero description coverage. The description compensates by identifying oid as the order ID, which is the essential semantic information needed to call the tool.

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: fetch detailed information for a specified order. It conveys that this is a single-order lookup rather than a list operation, though it does not explicitly distinguish itself from sibling tools like get_open_orders.

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 'specified order' implies use when you already have an order ID and need its details, but no explicit when-to-use or when-not-to-use guidance is given, and no alternative tools are mentioned.

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 no annotations, the description carries the behavioral burden. It discloses that the data comes from cache, is limited to L1, and depends on a prior subscription. It does not state the failure mode when the subscription is missing, but the key operational trait is clear.

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, dense sentences: one front-loads the action and prerequisite, the other documents the parameter. No filler or 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?

This is a simple one-parameter tool with an output schema available. The description covers purpose, parameter semantics, and the critical subscription prerequisite, which is enough for an agent to invoke 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 only says 'symbol' is a required string, so schema description coverage is 0%. The description compensates by explaining symbol as a trading pair and giving a concrete example, BTCUSDT-PERP.BINANCE.

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 a precise resource: the best bid/ask prices from the cached L1 order book. This clearly distinguishes it from balance, position, ticker, and kline siblings without needing to name 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?

It gives a clear precondition: '需要先预订阅 bookl1' (must pre-subscribe to bookl1 first), and indicates the data is cache-backed rather than a live fetch. It does not explicitly name alternatives or when not to use it, so it misses a 5.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and parameter; it does not explicitly confirm the operation is read-only, nor does it mention side effects, permissions, or rate limits. The verb '获取' (get) implies read-only, but it is not explicit.

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 extremely concise, consisting of a single purpose sentence and an args block. It front-loads the main action and is free of redundant or filler text, making it efficient for an agent 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 simple one-parameter getter with an output schema, the description covers the essential action and parameter. However, it lacks any usage guidance or explicit behavioral notes, which might be expected even for a simple tool. The absence of such context means an agent may not know when to choose this over get_all_positions, though the tool's simplicity mitigates the impact.

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 adds meaning beyond the schema's bare type by explaining that symbol is a trading pair and providing an example (BTCUSDT-PERP.BINANCE). This clarifies the expected format and domain, which the schema itself does not provide. It does not exhaustively describe all possible values, but it is helpful.

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 it retrieves position information for a specified trading pair, using a clear verb ('获取'/'get') and resource. It is distinct from siblings like get_all_positions (which likely returns all positions) and get_balance (which returns balances), so an agent can easily differentiate it.

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 offers no guidance on when to use this tool versus alternatives such as get_all_positions or get_balance. It does not mention conditions, exclusions, or scenarios where another tool would be more appropriate.

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 no annotations, the description carries the full burden. '列出' indicates a read-only list operation, and the optional instrument_type filter is described. However, it does not disclose side effects, pagination, error behavior, or what happens when instrument_type is null.

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 minimal and front-loaded: one clear purpose sentence followed by a compact argument list with examples. No redundant or filler 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?

Adequate for a low-complexity list tool, especially with an output schema available. It lacks usage differentiation from sibling market-info tools and does not specify behavior when instrument_type is omitted, so it is minimally viable but not fully self-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 compensate. It adds meaning by explaining exchange with examples (binance/bybit/okx) and instrument_type as an optional linear/spot/inverse filter. It does not explain null behavior, but it provides substantial value beyond the bare 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 clearly states '列出交易所可用交易对' (list available trading pairs), which identifies a specific verb and resource. It does not explicitly differentiate from siblings like get_exchange_info or get_market_info, but the intent is 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 provides parameter guidance and example values but gives no explicit when-to-use guidance or alternatives. It does not mention when to prefer this over get_exchange_info or get_market_info, so usage context must be inferred entirely from the purpose.

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 are absent, so the description must carry the behavioral disclosure burden. It discloses that the call is a REST request and non-cached, which is useful. However, it does not mention read-only nature (though implied by 'get'), potential rate limits, error handling, or what happens with invalid symbols. For a simple GET, this is a moderate gap, but not severe.

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 extremely concise: one sentence stating the core purpose and a separate 'Args' section for the parameter. It is front-loaded with the main action and avoids any redundant phrasing. Every word contributes to understanding, making it an efficient and well-structured definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter) and the presence of an output schema (which likely describes return values), the description is nearly complete. It covers the parameter semantics and the core behavior. The only missing element is explicit usage guidance relative to siblings, which is a minor gap. For a simple ticker getter, the description suffices for 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?

The schema provides no description for the 'symbol' parameter (0% coverage), so the description must compensate. It explicitly explains the parameter's purpose ('交易对' – trading pair) and gives a concrete example ('BTCUSDT-PERP.BINANCE'), which clarifies the expected format. This adds significant meaning beyond the bare type 'string', making it highly effective.

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 function: '获取指定交易对的最新行情' (get the latest quotes for a specified trading pair). It identifies the verb (get), resource (ticker/market data), and adds a behavioral note about being a REST request and non-cached. This distinguishes it from siblings like get_mark_price or get_index_price, which target different data types, even though no explicit comparison is made.

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 when you need the latest ticker for a specific symbol. However, it provides no explicit guidance on when not to use it or how it compares to alternatives like get_mark_price or get_index_price. There is no mention of exclusions or preferred scenarios, so the agent must infer the appropriate context from the name and sibling list.

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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It states the modification action and the optional side behavior, but does not disclose consequences, prerequisites, whether the original order is replaced, or any side effects. For a mutating tool, this is a significant gap.

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, front-loaded with the core purpose, and every sentence in the Args list adds meaning for a parameter. No filler or redundant restatement of the schema exists.

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?

All parameters are documented and an output schema is present, but the tool lacks usage guidance and behavioral details around order modification effects or error conditions. It is adequate for calling the tool, yet leaves important context to inference.

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 compensates fully by explaining every parameter: symbol is the trading pair, oid is the order ID, price and amount are the new values, and side is an optional new direction with the default behavior stated.

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 opening sentence clearly states a specific verb ('修改' / modify) and resource ('挂单' / open order), specifying price and quantity as the modified fields. The optional side argument is documented in the Args list, so the full scope of behavior is covered. This distinguishes it from sibling tools like create_order and cancel_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 implies usage: it is for modifying an existing open order, not for creating or canceling one. However, it provides no explicit when-to-use guidance, exclusions, or mention of alternative tools such as cancel_order + create_order.

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