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 includes important reminders about regional restrictions, KYC, security settings, and potential compliance changes. The detailed output example shows exactly what the tool returns, making behavior transparent, though it does not explicitly label the operation as read-only.

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 well-structured with headings and sections, but it is quite lengthy due to the extensive output example and reminders. While every section contributes value, it could be tightened without losing essential 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?

Given the tool has no parameters and no output schema, the description fully compensates by providing a comprehensive output example and usage scenarios. It covers all necessary aspects for an agent to understand when to use the tool and what it returns.

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 the baseline is 4. The description adds no parameter details, but none are needed since the tool requires no inputs.

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 Binance account basic information and permission status, specifying account type, trading/withdrawal/deposit permissions. However, it does not distinguish from the sibling tool binance_account_status, which may have overlapping functionality.

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?

Provides an '适用场景' (applicable scenarios) section listing four concrete use cases: verifying API configuration, pre-trading permission checks, troubleshooting, and compliance checks. This offers clear context but does not explicitly mention when not to use the tool 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a simple status check by explaining what is checked (connection, time sync, network mode, account config), the implications of issues (time deviation >1000ms affects calls), and provides a detailed output example. It also includes maintenance suggestions and fault-troubleshooting references, giving a complete picture of the tool's 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?

The description is excessively verbose, with emoji-heavy sections, a full example output report, and redundant advisory text (e.g., maintenance advice). While it is structured with headings, it contains far more detail than needed for a tool with no parameters and a straightforward purpose. Many sentences do not earn their 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 has no output schema and no annotations, the description fully compensates by explaining the return value in depth through an extensive output example. It covers the purpose, usage scenarios, interpretation of results, and troubleshooting, making it complete enough for an agent to select and invoke 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 tool has zero parameters and the schema coverage is 100%, so the baseline is 4. The description correctly implies no inputs are needed and instead focuses on the output report, which adds value by explaining what the user will receive.

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 checks API connection status, server time synchronization, and network mode (mainnet/testnet), positioning it as a diagnostic tool. This distinguishes it from sibling tools like binance_portfolio_account (balances) or binance_server_time (just time), by focusing on technical health.

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 usage scenarios (system startup, troubleshooting, regular health checks, new environment deployment) and even includes troubleshooting steps for common issues. It does not explicitly mention alternative tools or when not to use this one, but the context is sufficiently 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?

With no annotations provided, the description carries the full burden of transparency. It discloses that the tool analyzes shared risk across the unified account, accounts for dynamic market fluctuations, correlation risks, and liquidity risks, and provides a detailed sample report. This gives the agent a clear understanding of the tool's behavior and output without requiring annotation support.

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 quite lengthy, with extensive emoji formatting, repetitive warnings (e.g., '重要提醒' and '关键风险提醒'), and a very large output example. While it is well-structured and front-loaded with the core purpose, it could be more concise without losing essential 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?

The tool is complex with a rich output, and the description compensates for the lack of output schema and annotations by including a comprehensive example report that covers risk ratings, margin status, position analysis, stress testing, and optimization recommendations. It also lists applicable scenarios and risk warnings, making the tool's behavior fully understandable.

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 the schema coverage is 100%. The description focuses on the analysis scope and output format rather than parameter semantics, which is appropriate—there are no parameters to clarify. It meets the baseline for parameter-free tools.

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 this tool performs portfolio risk analysis on Portfolio Margin accounts, covering margin usage, position distribution, P&L, and asset quality. This clearly differentiates it from sibling tools like binance_portfolio_account or binance_futures_positions, which provide raw data rather than risk assessment.

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 dedicated '适用场景' section listing concrete use cases such as periodic risk review, margin optimization, institutional risk control, and personal asset health checks. While it doesn't explicitly name alternative tools, the context clearly indicates when this analysis tool is appropriate versus simple account/position queries.

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 and does so thoroughly. It discloses fee direction rules, 8-hour settlement cycle, dynamic rate behavior, cumulative cost implications, and risk warnings. It also provides a detailed output example showing exact return structure, which is critical since no output schema 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?

While quite long, the description is well-structured with emoji section headers, bullet points, and a full output example. The output example earns its length because without an output schema it is the only way to convey return format. However, it could be trimmed without losing essential 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?

Given the tool's moderate complexity, no annotations, and no output schema, the description is highly complete. It covers what the tool does, how it behaves, when to use it, what inputs are needed, what outputs to expect, and caveats/risks. The comprehensive output example fully compensates for missing structured output definitions.

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

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

Schema description coverage is 100%, so the baseline is 3. The tool description adds a concrete usage example with BTCUSDT and explains how inputs map to outputs, but the schema already fully documents each parameter's meaning and constraints. The description doesn't materially enrich parameter understanding beyond 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 it calculates the expected funding fee cost for USDT perpetual contracts, with a specific verb and resource. It distinguishes itself from sibling calculation tools like binance_calculate_position_size and binance_get_optimal_trade_size by focusing solely on funding cost estimation.

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 explicit applicable scenarios (long-term holders, arbitrage traders, risk systems, timing of entry/exit) and notes it applies only to USDT perpetuals (in schema). It doesn't explicitly mention when not to use or compare to alternatives, but the context is clear enough for appropriate selection.

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 carries the full burden. It discloses that the calculation respects minimum order quantity, provides a detailed output example showing risk calculations, margin requirements, and trading suggestions. It also includes warnings about leverage and stop-loss behavior. It doesn't explicitly state that no order is placed, but the calculator nature is clear, and the rich output example adds significant 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 excessively long and padded with generic trading advice (e.g., '盈利后可考虑移动止损保护利润', '不建议在重要数据发布前后开新仓位'). While it is structured with headings and front-loaded with the purpose, much of the content is not essential for tool invocation, making it verbose rather than concise.

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 includes a comprehensive output example that compensates for the lack of an output schema, illustrating the return format and calculations. It also covers usage context, risk warnings, and execution tips. It is complete enough for an agent to understand the tool's behavior and expected results, though it could be more explicit about edge cases or error handling, so a 4 is appropriate.

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

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

Schema description coverage is 100%, so the baseline is 3. The description simply lists the input parameters in the output example (risk amount, entry price, stop loss, leverage) but adds no additional meaning beyond what's already in the schema. It reinforces but doesn't expand parameter semantics, warranting a baseline 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?

Description clearly states it calculates contract position size based on risk parameters (risk amount, entry price, stop loss, leverage). It specifies '仓位大小计算器' (position size calculator) and explains it computes the optimal opening quantity, distinguishing it as a risk-management calculator. While a sibling 'get_optimal_trade_size' exists, the description's focus on stop-loss-based risk calculation gives it a distinct identity.

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 '适用场景' (applicable scenarios) section explicitly lists when to use the tool: for professional trading strategies, quant risk control, beginners learning position sizing, and risk systems setting max positions. This provides clear usage context, though it doesn't explicitly mention alternatives or when not to use it, stopping 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?

No annotations are provided, so the description carries the burden. It discloses that it checks real-time rules, validates precision/limits, and returns a detailed result with suggestions. It does not explicitly state it is non-mutating, but the checking nature and output example make side effects unlikely. 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 heavily structured with headings and emojis, and front-loads the core purpose. However, it is overly long due to a massive output example that repeats points and includes non-essential advice. Every sentence does not earn its place, so it's less concise than ideal.

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 compensates with a detailed example return format. It covers what parameters are checked, limitations, and applicable scenarios. However, it lacks failure case examples and doesn't describe error conditions or how to handle invalid symbols, leaving some completeness gaps.

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

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

Schema coverage is 100% and the parameter descriptions are already clear. The tool description adds a comprehensive output example that illustrates how parameters map to results, but it doesn't provide additional semantic detail beyond the schema fields themselves.

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 checks order parameters (price, quantity, limits) against trading pair precision requirements, using specific verbs and resource. It distinguishes itself from siblings like order placement and account info tools by emphasizing pre-order validation.

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 explicit applicable scenarios (pre-order validation, manual orders, trading bot risk control) and emphasizes checking before placing orders. It does not explicitly mention alternatives or when not to use, but the context is clear enough.

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 transparency burden. It discloses read-only analysis behavior, includes a detailed output example, and warns about volatility, costs, liquidity, and timeliness. It does not cover API-level details like authentication or rate limits, but for a simple comparison tool, it is sufficiently 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 overly long and cluttered with emojis, repeated risk warnings, and an extensive output example. The core information is buried under promotional formatting, and several sentences are redundant (e.g., multiple risk reminders repeated). It is not front-loaded, making it less efficient for an AI agent to parse quickly.

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 being verbose, the description is contextually complete: it explains the purpose, use cases, warnings, and includes a detailed output example that compensates for the lack of an output schema. For a single-parameter read-only tool, it covers all necessary aspects an agent needs to select and 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?

The input schema already provides 100% coverage for the only parameter 'symbol' with examples and a description. The tool description adds no new semantic meaning beyond confirming that the symbol is used to compare spot and perpetual futures prices, so the baseline score of 3 applies.

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 opens with '现货期货价差分析 - 套利机会智能识别' which clearly states it analyzes spot-futures price differences and identifies arbitrage opportunities. This verb+resource combination distinguishes it from sibling tools like binance_spot_price and binance_futures_price, which only fetch single-market prices.

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 '适用场景' section explicitly lists use cases: professional arbitrage traders, sentiment analysis, quant strategy evaluation, and risk monitoring. This provides clear context for when to use the tool, though it does not explicitly mention alternatives with when-not-to-use 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly warns about real-time updates, strict precision requirements, order size limits, API rate limits, and system maintenance periods. It also provides a detailed output example showing server time, system status, trading pair details, and API limits, which gives the agent a strong expectation of the data returned.

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 long but well-structured with clear sections (功能说明, 重要提醒, 适用场景, 输出示例) and uses bullet points and emojis for readability. It is front-loaded with the core purpose. The detailed output example is somewhat verbose but serves to set expectations for the return format, which is valuable given there is no output schema. Each section earns its place, though trimming the example could improve conciseness.

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 relatively simple read-only info tool with one optional parameter and no output schema. The description fully compensates by providing a comprehensive output example covering exchange base info, trading pair details, trading restrictions, other rules, API limits, and important notes. It also addresses key operational concerns like real-time updates and rate limits, making it complete for an agent to understand and invoke 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 input schema already has 100% coverage of the single parameter 'market', including an enum and a description explaining the difference between spot and futures. The description itself does not add further parameter-level detail, so the baseline score of 3 is appropriate. The output example implicitly illustrates spot market information, but this is not tied directly to the parameter semantics.

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: querying Binance exchange information and trading rules, including supported trading pairs, minimum order sizes, price/quantity precision, fee rules, and API limits. It is explicitly positioned as a foundational reference for programmatic trading and risk control, and the focus on exchange-wide rules clearly distinguishes it from sibling tools like account balances, orders, and 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 description provides a dedicated '适用场景' (applicable scenarios) section listing four specific use cases: programmatic trading systems, risk control verification, learning new trading pair restrictions, and compliance confirmation. This gives clear context for when to use the tool, though it does not explicitly mention alternatives or exclude scenarios that are better served by 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?

With no annotations, the description carries full burden and addresses key behavioral traits: it discloses that stats use mark prices to avoid anomalous fluctuations, explains funding fee direction, and highlights leverage effects. It also provides a comprehensive output example showing the exact data shape. However, it does not explicitly state that the operation is read-only, which is implicit but could be clearer.

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 highly structured with emojis, clear sections, and a detailed output example, making it easy to parse. However, it is somewhat verbose—some sections like '市场分析' and '交易提示' extend beyond essential tool behavior and into advisory content, which could be trimmed for token efficiency.

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 absence of an output schema, the description compensates with a thorough example output covering price, volume, funding rate, open interest, and analysis. It also explains use cases and important metrics, making it complete for a market data tool. Minor gaps exist around error cases or rate limits, but these are not critical for this type of 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 already provides 100% coverage with a clear description and examples for the symbol parameter. The description does not add further parameter-level detail, but since the schema is sufficient, a baseline score of 3 is appropriate.

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 retrieves 24-hour market statistics for perpetual futures contracts, including price change, volume, funding rate, and open interest. It distinguishes itself from spot by explicitly noting it provides richer data, making it distinct from sibling tools like binance_spot_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?

The '适用场景' section provides clear contexts: futures traders analyzing opportunities, arbitrage traders monitoring spot-futures spread, risk managers evaluating volatility, and fund managers analyzing funding rates. It lacks explicit 'when not to use' or naming alternatives, but the scenarios effectively imply when this tool is appropriate vs spot equivalents.

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 carries the full burden and does an excellent job: it discloses that only NEW and PARTIALLY_FILLED orders are canceled, that the operation is irreversible, that it returns per-order results and margin release info, and that failures can occur. The detailed output example further clarifies 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?

The description is front-loaded with a clear one-liner, then organized into sections for function, danger warnings, applicable scenarios, and output examples. It is somewhat long due to the extensive sample output, but the structure and repeated warnings are appropriate for a destructive operation.

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 cancel-all operation with no annotations and no output schema, the description is fully self-sufficient. It covers what the tool does, which order types are affected, irreversibility, applicable scenarios, and provides a detailed output example that substitutes for a formal output 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 input schema already describes the symbol parameter as required and explains that it specifies the contract whose all orders will be canceled. With 100% schema description coverage, the description adds no new parameter-level details beyond restating 'specified contract', hitting the baseline of 3.

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 opens with '一键取消指定合约的所有委托订单' (one-click cancel all orders for a specified contract), which is a specific verb+resource+scope statement. It clearly distinguishes this from the sibling binance_futures_cancel_order by targeting all orders for a contract rather than a single 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 lists concrete applicable scenarios (rapid market shifts, strategy changes, system maintenance, avoiding risk) and warns that the operation is dangerous. However, it does not explicitly mention alternatives like binance_futures_cancel_order for canceling a single order, so it stops short of full when-not/alternative 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?

With no annotations, the description carries the full burden of disclosing side effects. It clearly states that only NEW or PARTIALLY_FILLED orders are cancellable, that margin is released immediately, and that filled or already-cancelled orders cannot be cancelled. It also provides a detailed output example showing the response structure. It could mention error cases or rate limits, but overall it is 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 well-structured with clear sections for features, warnings, scenarios, and a sample response. It is somewhat long, but each section contributes valuable information without redundancy. The emoji and headers improve readability.

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 no output schema, but the description compensates with a detailed success example. It explains cancellation conditions and margin release, and includes usage scenarios. It lacks explicit error handling or rate-limit information, but for a 2-parameter mutation tool, the description is largely 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 coverage is 100% for both parameters, with schema descriptions already explaining the need for exact symbol matching and how to obtain orderId. The tool description itself adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.

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 cancels a specified contract (futures) order: '取消合约市场的指定委托订单'. It uses a specific verb (取消) and resource (合约订单), clearly distinguishing from sibling tools like cancel_all_orders by emphasizing '指定' (specified).

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 includes an '适用场景' (applicable scenarios) section listing concrete use cases such as market shifts, strategy adjustments, and risk control. It also references an alternative for viewing orders (binance_futures_open_orders) in the schema. However, it does not explicitly compare with cancel_all_orders or spot cancel, leaving some room for improvement.

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 carries full burden. It discloses that changes take effect immediately, do not affect current positions but only new orders, and alter margin requirements and risk levels. The risk warnings about liquidation and leverage impact add important behavioral context.

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 well-structured with clear section headers, but it is quite verbose, including a lengthy output example and repeated risk warnings. It front-loads the core purpose, yet could be trimmed to essential information without losing value.

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 lacking annotations and an output schema, the description provides a detailed output example, functional details, risk analysis, and suggested actions. It gives the agent sufficient context to understand behavior, edge cases (adjust with no positions), and 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?

Input schema covers both symbol and leverage with descriptions, examples, and ranges, achieving 100% coverage. The description adds no additional parameter-specific semantics beyond referencing the 1-125 range, so baseline 3 is appropriate.

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 modifies the leverage multiplier of a specified contract (修改指定合约的杠杆倍数) and includes a functional overview listing key effects like immediate implementation and impact on new orders. This clearly distinguishes it from sibling tools such as set_margin_type or account queries.

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 '适用场景' section provides clear use cases like adjusting risk exposure and optimizing capital efficiency, and the reminder advises adjusting when not holding positions. However, it does not explicitly mention when not to use this tool or name alternative tools, so it lacks exclusions.

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 carries the full burden. It discloses irreversibility, market slippage risk, margin release, and supports both one-way and two-way position modes. It lacks explicit permission/authorization requirements but covers the key operational consequences well.

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 well-structured with emoji section headers, but is quite long, especially the extensive output example. It is front-loaded with the core function and warnings, but the length borders on verbose for a tool that could be summarized more succinctly.

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 there is no output schema, the description compensates with a detailed output example covering fill details, fees, PnL, margin changes, and suggestions. It covers use cases, warnings, and behavior, but could mention error cases or prerequisites like account permissions.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds useful context about auto-calculating direction/quantity and supporting both position modes, which aligns with the schema parameters. But it does not add significant extra meaning beyond the schema's already clear 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 clearly states it performs market-price one-click closing of all positions for a specified contract, with automatic direction and quantity calculation. It distinguishes itself from sibling tools like place_order or cancel_order by focusing specifically on closing existing positions.

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?

Explicit '适用场景' section lists when to use (emergency stop loss, market reversal, strategy adjustment, risk management). It does not explicitly state when NOT to use it or alternatives, but the scenarios are concrete and actionable.

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 and discloses key behavioral traits: mark price basis, removal of abnormal fluctuations, leverage amplification, funding rate, and liquidation risk. It also includes a detailed output example showing expected structure, providing 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 excessively long, with emojis, a lengthy fake output example, and trading tips that are not necessary for tool invocation. While structured with clear sections, it violates the principle that every sentence should earn 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?

Despite no output schema, the description includes a comprehensive output example with price, volume, and market features, plus contextual warnings about leverage and funding. It fully equips the agent to understand the return data and risk factors, making it complete for a data query 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?

Schema coverage is 100% and each parameter already has detailed descriptions. The description adds minor trading advice for limit and interval but does not materially enhance parameter semantics beyond what the schema provides, aligning with the baseline for high schema coverage.

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 retrieves historical candlestick data for perpetual futures contracts based on mark price, using a specific verb+resource structure. It explicitly distinguishes from spot klines, which differentiates it from the sibling tool binance_spot_klines.

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?

Provides explicit use cases (trading strategies, arbitrage, risk management, backtesting) and positions itself as dedicated to perpetual contract technical analysis. It implies comparison with spot data but does not explicitly name alternative tools or exclusion scenarios.

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 carries the full burden and does so well. It discloses that only NEW and PARTIALLY_FILLED orders are returned, warns about potentially large datasets when querying all contracts, and details the information returned (price, quantity, margin usage, etc.). This goes well beyond the basic read-only nature implied by the tool name.

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 well-structured with clear sections and front-loaded with a concise function summary. While the output example is lengthy and contains some potentially redundant details, it adds value because there is no output schema. Overall, the structure is organized but the example could be trimmed.

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 is highly complete: it explains the query scope, the returned order statuses, the returned details, margin analysis, and includes a comprehensive output example. This gives the agent enough context to select the tool correctly and understand what will be returned.

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 already provides 100% coverage for the only parameter (symbol), including examples and usage recommendations. The description adds only marginal value by mentioning contract filtering without supplying new semantic details beyond what the schema already states, so the baseline score of 3 is appropriate.

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 queries all unfilled futures orders (NEW and PARTIALLY_FILLED) with a specific verb+resource. It distinguishes itself from sibling tools by explicitly describing the order statuses and its focus on open orders, which is distinct from order history or cancellation 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 provides a clear '适用场景' section listing concrete use cases such as checking pending orders before batch cancellation and monitoring margin usage. It also advises specifying a contract to avoid large data volume, but it does not explicitly mention when not to use the tool or name alternative 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?

With no annotations, the description carries the full burden. It discloses important behavioral traits: returns all order statuses, enforces a 7-day time window, defaults to descending order, and supports pagination via orderId. It includes a detailed output example showing the expected result format and derived statistics (e.g., success rate). It does not mention error handling or rate limits, but for a read-only query tool this is sufficient context.

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 well-structured with clear sections (功能说明, 重要提醒, 适用场景, 输出示例). It front-loads the core purpose and important constraints. The output example is long but serves as a useful concrete illustration for an agent. Some redundancy exists (7-day limit appears in both features and reminders), but the overall size is appropriate for a tool with 5 parameters and no output 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?

Given the tool's complexity (5 params, no output schema, no annotations), the description covers key aspects: query scope, time constraints, pagination, sorting, and expected output through the example. It lacks details on API authentication, rate limiting, or possible error responses, but those are less critical for an agent choosing to invoke the tool. The provided example compensates for the missing output 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 coverage is 100%, so baseline is 3. The description adds value beyond the schema by emphasizing key usage constraints: '每次查询只能指定一个合约' (one symbol per query), '默认按时间倒序返回' (default descending sort), and advising to use limit for large datasets. It also clarifies the optionality and behavior of startTime/endTime, which the schema already documents but the description reinforces with practical context.

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 queries historical contract orders ('查询合约市场的历史订单记录') and lists the specific statuses included (已成交、已取消、被拒绝、已过期). It distinguishes itself from sibling tools like binance_futures_open_orders by explicitly covering all historical orders, not currently open ones. The verb '查询' is specific and resource-bound.

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?

Provides a dedicated '适用场景' section listing concrete use cases (viewing history/PnL, analyzing strategy success, verifying fees, exporting data). It also gives practical constraints (one contract per query, 7-day max range, use limit for large data). However, it does not explicitly contrast with sibling tools like binance_futures_trade_history or mention when NOT to use this tool, so it lacks explicit exclusions.

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 carries the full burden. It discloses risk warnings (high risk, margin needs, leverage amplification), mentions '自动计算保证金需求和风险参数', and includes a detailed output example showing execution status, margin details, PnL predictions, and suggested actions. This goes beyond simple 'places order' and describes order lifecycle behavior. However, it does not mention error handling or rate limits.

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 long and uses multiple sections with headers and emojis, but the output example is very verbose (about 30 lines) and could be trimmed for conciseness. The structure is organized and readable, but not every sentence clearly earns its place in a tool description.

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 10 parameters, no annotations, and no output schema, the description is quite comprehensive. It covers purpose, usage scenarios, risk warnings, and provides an illustrative output. It indirectly references other tools in the schema (exchange info, precision check). Missing error scenarios or authentication details, but overall it gives sufficient context for an agent to select and invoke the 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?

Schema description coverage is 100% with detailed per-parameter explanations, including enums, examples, and tips. The tool description adds no specific parameter semantics beyond restating order types and auto-calculating margin. It relies on the schema for parameter meaning, which is the expected baseline when coverage is high.

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 tool submits trading orders on Binance perpetual futures ('在Binance永续合约市场提交交易订单'), enumerates supported operations (open/close/add/reduce positions) and order types (market, limit, stop, take-profit). This specific verb+resource combination distinguishes it from spot trading and sibling tools like binance_spot_place_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 '适用场景' section lists clear contexts: bullish/bearish speculation, leverage amplification, hedging spot positions, and quant trading. It implicitly indicates futures usage but does not explicitly name alternatives or state when not to use this tool. Cross-references to exchange info appear in the schema, not the description.

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 warns about liquidation risk, mark price vs. last price differences, leverage risk, and funding fees, and explains that the output includes real-time risk data and today's PnL. It also provides a detailed output example that reveals the exact structure and fields returned. Missing details like error handling are minor for a read-only query 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 well-structured with clear headers (功能说明, 重要提醒, 适用场景, 输出示例) and front-loads the purpose. However, it is quite verbose, especially the sprawling output example with emojis and repeated warnings. While informative, it could be more concise without losing value.

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 lacking an output schema, the description provides a comprehensive output example that acts as an informal schema, covering all key position fields, risk metrics, and overall analysis. It also includes applicable scenarios and risk warnings, making the tool's behavior fully understandable. The one optional parameter is thoroughly covered by the schema, so nothing 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?

The input schema already thoroughly documents the 'symbol' parameter with examples and states that omitting it returns all positions. The description only restates '支持查询特定合约或所有持仓' without adding new semantic details. Since schema coverage is 100%, this meets the baseline but doesn't surpass it.

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 immediately states '合约持仓查询' (futures position query) and lists specific data returned (持仓数量, 入场价格, 标记价格, 未实现盈亏, 强平价格, 杠杆倍数), making the tool's purpose unmistakable. It clearly distinguishes itself from sibling tools like order placement or account balance queries.

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 dedicated '适用场景' section listing specific use cases (monitoring positions, risk control, strategy verification, portfolio analysis), giving clear context for when to use the tool. It doesn't explicitly mention exclusions or alternatives, but the scenarios are sufficiently clear for an agent to choose this over other Binance 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?

With no annotations provided, the description fully covers behavioral traits. It explains that mark price differs from last price, is the basis for settlement and forced liquidation, is more stable against manipulation, and that batch queries are limited to the first 100 active contracts. The output example also discloses the return structure and how to interpret funding rate and basis.

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 well-structured with clear sections and front-loaded with the main purpose. However, it is verbose, including a multi-line output example with emojis. While the structure aids readability, the length exceeds what is strictly necessary for tool selection, but the output example is useful given the lack of an output schema.

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

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

The tool has no output schema, so the description compensates by providing a detailed output example and behavioral notes. It covers return format, interpretation of price discrepancy, funding rate implications, and market status. Combined with the use cases and warnings, the description is fully complete for an agent to use the tool effectively.

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 already provides comprehensive parameter documentation for the optional `symbol`, including examples and behavior when omitted. Since schema coverage is 100%, the description adds no additional parameter semantics beyond what the schema provides, warranting the baseline score of 3.

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 purpose: "获取合约市场的实时标记价格信息" (Get real-time mark price information for futures market). It uses a specific verb (获取) and resource (合约市场的实时标记价格), and distinguishes itself from spot price by emphasizing the mark price, which is the settlement and liquidation basis.

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 an "适用场景" (applicable scenarios) section listing contract trading reference, risk management, liquidation monitoring, and arbitrage analysis. This gives clear context for when to use the tool, though it does not explicitly state when not to use it or name alternative tools. The explicit warning about the batch limit and the distinction from spot price provide additional 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?

Without annotations, the description carries the full burden. It discloses key behavioral traits: immediate effect ('立即生效'), no impact on current positions ('不影响当前持仓'), and per-contract independence ('每个合约可以独立设置不同的模式'). It also explains the downstream implications of each margin mode (risk isolation vs. high capital efficiency). The output example further illustrates the response format and mode comparison. There is no contradiction with any annotations, as none are provided.

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 well-structured with headers and bullet points, but it is verbose. The output example is quite long and includes redundant sections (e.g., '模式对比' and '建议操作') that repeat information already in the main text. While the structure improves readability, the length exceeds what is necessary for an agent to understand the tool. Some content could be trimmed without losing semantic value.

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 two-parameter setting tool, the description is exceptionally complete. It covers purpose, behavior, risk implications, and even provides a detailed output example. The lack of an output schema is compensated by the example, which illustrates the exact response structure. No critical information is missing for an agent to select and invoke 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 input schema already provides 100% coverage, with both parameters clearly described: symbol examples and marginTypes enum with explanations. The description does not add additional parameter-specific semantics beyond what the schema already provides; it merely references '合约' and modes, which are already in the schema. Per the calibration baseline, a score of 3 is appropriate when schema handles the heavy lifting.

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 opens with a clear statement of the tool's purpose: '设置指定合约的保证金模式' (set margin mode for specified contract), which directly defines the verb+resource. It distinguishes this from sibling tools like binance_futures_change_leverage by focusing specifically on margin mode selection. The description also clarifies the two modes (逐仓/全仓) and the independence of settings per contract.

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 contextual guidance, including a dedicated '适用场景' (applicable scenarios) section and important reminders such as '建议在无持仓时调整保证金模式' (recommended to adjust when no positions) and '新手建议使用逐仓模式' (beginners recommended to use isolated mode). While it doesn't explicitly name alternative tools, it gives enough context to understand when this tool is appropriate relative to other account/position management 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?

With no annotations, the description carries the full burden and does well. It discloses that only actual filled trades are returned, not open orders, that each query is limited to one contract, and that the time range cannot exceed 7 days. The output example also reveals the response structure, including fee and PnL fields. Missing explicit error/edge-case behavior prevents a 5.

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 well-structured with clear headings, bullet lists, and a comprehensive output example. While it is quite long, every section adds value, especially the detailed example that compensates for the lack of an output schema. It is more verbose than ideal but not redundant.

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 5-parameter tool with no output schema and no annotations, the description is remarkably complete. It explains the return format via a detailed example, covers key constraints, and provides real-world use cases. The output example alone gives the agent a clear picture of what to expect, so no critical information 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?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds only general mentions of time range and pagination ('支持时间范围和分页查询'), but does not provide additional semantics beyond the schema. Baseline 3 is appropriate.

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 queries actual futures market trade details ('查询合约市场的实际成交明细'). It distinguishes itself from order history by emphasizing it only shows filled trades, not unfilled orders, and from spot tools by explicitly saying '合约' (futures). This is specific and 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 '适用场景' section provides clear use cases (cost calculation, PnL reconciliation, tax reporting), and constraints like '每次查询限定一个合约' and time range limits inform when it's appropriate. However, it does not explicitly name sibling tools as alternatives or state when not to use it, 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 fully carries the behavioral burden. It discloses the methodology (逐档累计价格影响), output format (报告), safety margin (20% liquidity buffer), dynamic nature (实时变动), and risk implications (market impact, batch execution advice). This gives the agent a thorough understanding of the tool's 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?

The description is extremely verbose, with extensive emoji formatting, multiple repetitive warning sections, and a full mock output report. While well-structured with headers, the core message is scattered and the length is disproportionate for a tool description, failing the 'every sentence earns its place' test.

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 lacking an output schema and annotations, the description provides a complete picture: detailed output example, technical details, usage scenarios, execution advice, and risk warnings. For a complex analysis tool, this is highly comprehensive and gives the agent all context needed to understand what the tool returns and how to interpret 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 100% with detailed parameter explanations (e.g., side affects liquidity analysis, maxPriceImpact defines acceptable slippage). The description's output example implicitly illustrates how maxPriceImpact and side are used, but it does not add direct semantic value beyond what the schema already provides, warranting the baseline 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 clearly states the tool is an optimal trade volume calculator that minimizes liquidity impact using order book depth analysis. It uses a specific verb ('计算') and resource ('最优交易量'), and the detailed functionality ('深度分析市场流动性分布，计算不同交易量对价格的潜在冲击') distinguishes it from sibling tools like position sizing or order placement 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 '适用场景' section explicitly lists when to use the tool (large trade assessment, institutional risk management, HFT optimization, liquidity research). It provides clear context for use, though it does not explicitly mention alternatives or when not to use it, which would have earned 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 fully carries the burden. It explicitly warns about margin sharing risks, liquidation risk, calculation complexity, and real-time fluctuations. The output example also reveals the response format and fields.

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 long but well-structured with emoji headers, sections for features, warnings, scenarios, and an output example. It's front-loaded with a summary sentence and each section has purpose, though it could be trimmed slightly for brevity.

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 annotations and no output schema, the description provides a complete picture: functionality, risk implications, use cases, and an example output. This fully compensates for missing structured metadata.

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's no parameter to explain. The description compensates by detailing the output data structure, but the baseline for a zero-param tool is 4; it doesn't add extra param-level semantics beyond that.

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 '获取统一账户（Portfolio Margin）的完整信息' (get complete info of unified account), which clearly identifies a specific verb and resource. It distinguishes from siblings like binance_account_info by focusing on Portfolio Margin unified account and cross-spot/futures asset view.

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 '适用场景' section lists concrete use cases such as professional traders viewing asset allocation, monitoring margin usage, and risk control. It doesn't explicitly mention alternatives or exclusion criteria, but the context is clear and domain-specific.

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 carries the full burden of behavioral disclosure. It thoroughly explains that the tool compares server and local times, calculates network delay, and provides a detailed output example including time deviation, sync status, and recommendations. It also warns about the 1000ms threshold and suggests periodic checks, giving complete 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 well-structured with clear sections (功能说明, 重要提醒, 适用场景, 输出示例, 故障排除) and front-loaded purpose. While it is lengthy, each section provides value, including warnings, use cases, and a detailed output example. It is not unnecessarily bloated, though the extensive emoji-laden output example could be trimmed.

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 there is no output schema and no annotations, the description compensates fully by providing a comprehensive output example, interpretation guidance, and troubleshooting steps. It leaves no gaps about what the tool returns and how to interpret the result, making it complete for a zero-parameter utility 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 tool has zero parameters, so the description cannot add parameter-level detail. Per the rubric, the baseline for 0 params is 4. The description adds meaningful context about what the no-input tool does and what output to expect, which is sufficient.

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: '获取Binance服务器的当前时间，并与本地时间进行对比分析' (retrieves Binance server time and compares with local time). It uses a specific verb and resource, and it is clearly distinguishable from all sibling tools, which focus on trading, account, 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 description provides explicit '适用场景' (applicable scenarios) such as checking time sync at startup, troubleshooting API failures, and system monitoring. It gives clear context for when to use the tool, though it does not explicitly mention when not to use it or name alternatives (which are absent among siblings).

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 carries the full burden of behavioral disclosure. It reveals that data is a rolling 24-hour window updated every second, mentions data completeness, market activity metrics, and provides a detailed output example. This goes beyond minimal expectations.

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 well-organized with clear sections and front-loaded function explanation. The extensive output example is valuable but makes the description somewhat long; still, every section serves a 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 simple read-only tool with one optional parameter and no output schema, the description is complete. It explains what the tool does, when to use it, behavioral details, and provides an output example that substitutes for a 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 input schema already provides 100% coverage for the only parameter 'symbol' with examples and explanation. The description does not add extra parameter semantics beyond what the schema offers, so the baseline of 3 applies.

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 retrieves 24-hour spot market price statistics, including specific metrics like price change, volume, high/low, and weighted average price. It explicitly says '现货市场' (spot market), distinguishing it from futures ticker 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?

The description provides clear usage contexts under '适用场景' (applicable scenarios) for investors, traders, analysts, and risk control. It implies when to use the tool, though it does not explicitly name alternative tools or state when not 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?

With no annotations, the description fully covers behavioral traits: it notes that frozen balances include funds from pending orders, balances are real-time, precision varies by coin, and only quantities are shown (no USD valuation). The output example further clarifies the exact structure and status flags, making behavior highly 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 well-structured with sections (功能说明, 重要提醒, 适用场景, 输出示例) and front-loaded with a summary. While it is lengthy, the example output and warnings earn their place by providing concrete return format and operational caveats. Slight redundancy in the example (e.g., repeated '资金状态') prevents a 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?

Given no annotations and no output schema, the description is remarkably complete. It explains the tool's scope, output format via a detailed example, behavioral nuances (real-time, precision, frozen order funds), and usage contexts. There are no gaps in what the agent needs to know to invoke this 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 tool has zero parameters, and the schema covers 100% of nothing. Baseline for 0 params is 4. The description adds value by explaining what the returned data represents (available, frozen, total), but there are no parameter details to elaborate on.

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 purpose: '查询现货账户中所有币种的余额情况，包括可用余额、冻结余额和总余额' (query all coin balances in spot account including available, frozen, and total). It specifies the resource (spot account balances) and the action (querying), and distinguishes itself from siblings by emphasizing spot balances and auto-filtering zero balances.

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 usage context with '适用场景' (applicable scenarios) listing specific use cases like checking asset allocation and verifying available balance. It also gives an alternative guidance: '如需USD估值请使用价格工具计算' (for USD valuation use price tool). However, it doesn't explicitly contrast with sibling tools like binance_account_info or binance_portfolio_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?

With no annotations provided, the description fully carries the burden. It discloses irreversibility, the specific order states affected, unfreezing of funds, and per-order success/failure outcomes. The danger warning and output example make side effects 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 well-structured with clear sections (function, danger, use cases, output example) and front-loaded purpose. It is long, but the detail is justified for a dangerous irreversible operation. The output example is extensive but could be slightly condensed without loss.

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 no output schema, the description provides a comprehensive output example covering success/failure counts, order IDs, released funds, and suggestions. It also covers prerequisites, effects, and alternative verification. This makes the tool's behavior fully understandable.

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 for the only parameter (symbol) is 100%, including format, case-sensitivity, and warnings. The main description adds little beyond the schema itself (only an example in the output section). Baseline 3 is appropriate since the schema does the heavy lifting.

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 cancels all open orders for a specified trading pair in one click, specifying order states (NEW, PARTIALLY_FILLED). It distinguishes from sibling tools like single-order cancel (binance_spot_cancel_order) and futures cancel-all (binance_futures_cancel_all_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?

Provides explicit applicable scenarios (e.g., market volatility, strategy failure) and warns against misuse. It recommends checking open orders first with binance_spot_open_orders, directly guiding when to use vs. 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?

No annotations are provided, so the description carries the full burden. It discloses that only NEW/PARTIALLY_FILLED orders can be canceled, cancellation is immediate and irreversible, frozen balance is released, and the response includes order details and execution status. This goes well beyond the annotations and gives the agent a thorough understanding of 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 front-loaded with the purpose and uses clear sections with emojis, making it scannable. However, it is verbose, with some redundant statements (e.g., '只能撤销未完全成交的订单' and '已成交或已撤销的订单无法再次撤销') and a lengthy output example that repeats details. Despite this, the structure aids comprehension and the output example is valuable given no output 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?

Given only two parameters, full schema coverage, no annotations, and no output schema, the description compensates well by explaining the order states that are cancelable, the side effects, applicable scenarios, and a detailed output example. There are no significant gaps in understanding what the tool does, when to use it, or what to expect.

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 covers 100% of the parameters (symbol and orderId) with detailed explanations, examples, and notes. The description itself does not add any parameter-level meaning beyond what is already in the schema, so the baseline score of 3 applies.

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 cancels a specified order in the spot market using the verb '取消' (cancel) and identifies the resource as '现货市场的指定委托订单' (a specified order in the spot market). It distinguishes from siblings like 'binance_spot_cancel_all_orders' by specifying a single order, and from futures tools via the '现货' (spot) qualifier.

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 applicable scenarios (price changes, strategy adjustment, risk management) and explicitly excludes orders that are fully filled or already canceled, noting only NEW and PARTIALLY_FILLED orders can be canceled. However, it does not mention when to use the alternative 'binance_spot_cancel_all_orders' or the futures counterpart, so it lacks explicit when-not-to-use 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?

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

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

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

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

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

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

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

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

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

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

With no annotations, the description carries full responsibility. It discloses that only NEW and PARTIALLY_FILLED orders are returned, executed/canceled orders are excluded, querying all may return large data, and it provides a detailed output example showing the exact response format including frozen funds. This is highly 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 well-structured with headings and emojis, but it is quite long due to a detailed output example and 'suggested actions' section. The output example adds value for transparency, but the 'suggested actions' are somewhat extraneous for tool selection. It is appropriately front-loaded but not concise.

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?

Considering the simple tool (1 optional param, no annotations, no output schema), the description is exceptionally complete. It explains filtering options, statuses, data volume considerations, use cases, and provides a full output example, giving the agent everything needed to use 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 input schema already describes the single 'symbol' parameter with examples and usage tips (100% coverage). The description mentions filtering by pair or querying all, which repeats schema content but doesn't add new syntax or format details. Thus the basis is 3, as schema does the heavy lifting.

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 '查询现货市场当前所有未成交的委托订单' (query all current unfilled orders in the spot market), identifying a specific verb and resource. It distinguishes from sibling tools by explicitly noting it is for spot (现货) and includes only unexecuted orders, unlike order history or futures 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 provides explicit use cases (checking current orders, before batch cancel, monitoring progress, strategy adjustments) and recommends specifying a trading pair for efficiency. It also warns about large data volumes when querying all. However, it does not explicitly exclude when not to use it compared to futures tools, though the spot designation makes that 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?

No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: the order book changes rapidly ('订单簿数据实时变化，瞬息万变'), hidden iceberg orders may not appear ('大单可能不在订单簿中显示'), and data is for reference only. The output example also gives a sense of the response format. However, it does not mention rate limits, authentication requirements, or whether the output is JSON vs a formatted string.

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 well-structured with clear section headers (功能说明, 重要提醒, 适用场景, 输出示例) and uses emojis for readability. However, the output example is excessively long and takes up a large portion of the text, making it less concise. Every section earns its place, but the example could be trimmed to essential 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?

Given there is no output schema and no annotations, the description compensates well by providing purpose, usage scenarios, warnings, and a detailed output example. It covers the essential aspects of the tool for an agent to select and invoke it correctly. The main gap is the lack of explicit return type (JSON vs formatted text) and any error handling notes, but overall it is reasonably complete for a simple market data 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?

Schema description coverage is 100%, with both 'symbol' and 'limit' already well-described in the input schema. The description itself does not add extra parameter semantics beyond the schema; for example, the output example shows '深度级别：10档' but that's just an illustrative value. The default value and enum are already 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 the tool's function: '获取现货市场的买卖盘深度信息' (get spot market bid/ask depth information). It explicitly mentions displaying bid and ask price/quantity distribution and analyzing liquidity, which distinguishes it from sibling tools like price checkers or klines.

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 specific applicable scenarios (analyzing market depth, finding support/resistance, optimizing limit orders, assessing market impact), giving clear context for when to use the tool. However, it does not explicitly mention alternatives or when not to use it, such as comparing with futures orderbook or using klines for historical analysis.

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 discloses key behaviors: each query is limited to one symbol, time range cannot exceed 24 hours, results are sorted descending by default, and the limit parameter is recommended for large datasets. The provided output example also illustrates the response structure and content, giving agents a clear picture of what 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 well-structured with clear sections and front-loaded purpose and reminders. The output example is extensive but justified since there is no output schema, yet it makes the description longer than strictly necessary. Overall it is organized and readable, but slightly verbose.

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 there is no output schema, the description compensates with a detailed output example showing query summary, execution stats, and per-order details. Combined with the thorough schema, all parameters and behavioral constraints are adequately covered. The description also includes practical tips for pagination and time-range usage, making it complete for an agent to invoke 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?

Schema description coverage is 100%, and each parameter already has detailed explanations with examples and tips. The main description adds general reminders (e.g., single symbol, 24-hour limit) and an output example, but it does not significantly enhance the parameter-level semantics beyond what the schema already provides. Thus the baseline score of 3 is appropriate.

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 opens with a clear verb and resource: '查询现货市场的历史订单记录' (query spot market historical order records). It explicitly lists the order states covered (filled, canceled, rejected, expired) and distinguishes itself from sibling tools like binance_spot_trade_history by focusing on order records rather than trade records.

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 '🎯 适用场景' (applicable scenarios) section listing concrete use cases such as viewing historical records, analyzing execution, and verifying account details. It also gives '⚠️ 重要提醒' (critical reminders) with constraints like single trading pair and 24-hour limit. However, it does not explicitly mention alternatives or exclusion scenarios, 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 full burden. It discloses that market orders execute immediately, limit orders may partially fill or wait, and funds are frozen. The output example shows order status and balance impact. However, it does not mention fee deductions, slippage, or error handling on insufficient balance.

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 long but well-structured with headers, bullet points, and a complete output example. Every section adds value, though some redundancy with schema descriptions exists. It is front-loaded with the main action and remains readable.

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 complex place-order tool with 7 parameters and no output schema. The description covers functionality, usage scenarios, warnings, and an output example, making it comprehensive. It lacks explicit error scenarios or rate limits, but is sufficient for an agent to understand and invoke the 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 input schema already provides 100% coverage with detailed descriptions for all 7 parameters, including examples and enums. The description adds an output example and general tips, but does not significantly enhance parameter semantics beyond what the schema already provides.

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 places orders in Binance spot market, lists supported order types, and the title '现货下单' (spot order) distinguishes it from futures order tools. It also differentiates from sibling tools like cancel order and order history by focusing on order submission.

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 includes a '适用场景' section listing when to use (buy/sell, take-profit/stop-loss, arbitrage) and a reminder about order cancellation using other tools. It also warns about balance requirements and market order behavior, but doesn't explicitly exclude futures or other 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?

With no annotations, the description carries the full burden. It discloses real-time updates, millisecond fluctuations, the 100-pair batch limit, and that prices are reference-only. It also adds data source and latency details ('Binance 官方 API', '< 100ms'), providing useful behavioral context.

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 well-structured with clear sections, but it is verbose. Decorative emojis and a redundant '交易提示' block add length without enhancing understanding. The output example is useful but could be trimmed.

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 single-optional-parameter tool with no annotations or output schema, the description covers use cases, behavioral warnings, limits, and an illustrative output. Missing details about multi-pair input format are the main gap, but overall it is sufficiently complete for an agent to invoke the 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?

Schema coverage is 100% for the single symbol parameter, so the baseline is 3. The description adds a generic '支持单个查询或批量查询' but does not clarify how batch input should be formatted (e.g., comma-separated list), which is a gap since the schema only shows single-pair examples.

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 '获取现货市场的实时价格信息' (get real-time spot market price information), clearly identifying the verb and resource. It distinguishes from siblings like binance_futures_price by specifying '现货' (spot) and from orderbook/ticker tools by focusing on price.

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 '适用场景' section provides clear use cases (market monitoring, pre-trade reference, portfolio valuation) and the '重要提醒' warns about batch limits and price volatility. However, it does not explicitly name alternative sibling tools or state when NOT to use this 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?

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: only actual trades are returned (not unfilled orders), each query is limited to one trading pair, time range cannot exceed 24 hours, and both buyer and seller fee information is included. This gives substantial insight beyond the 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?

The description is well-structured with clear sections and front-loads the purpose. However, the output example is lengthy, adding many lines of detail. While it aids understanding of the return format, it could have been trimmed without losing essential meaning.

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, no output schema, and no annotations, the description is remarkably complete. It explains constraints, use cases, and provides a detailed output example that compensates for the missing output schema. This is more than sufficient for an agent to invoke 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?

Schema description coverage is 100% with detailed explanations for each parameter, so the baseline is 3. The tool description itself does not add significant parameter semantics beyond the schema; it focuses more on the tool's function and output.

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 '查询现货市场的实际成交明细' (query actual trade details in the spot market), with a specific verb and resource. It distinguishes itself from order history by emphasizing it shows only actual fills, not unfilled orders, which differentiates it from siblings like binance_spot_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?

The description provides '适用场景' (suitable scenarios) such as cost calculation, reconciliation, and tax reporting, and includes '重要提醒' with explicit exclusions (one trading pair, 24-hour limit). However, it does not explicitly name alternative sibling tools, so the guidance is clear but not fully comparative.

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