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

Annotations only declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds crucial behavior: irreversible funds movement, the kill-switch and its bypass prevention, error handling for expired quotes, and the meaning of orderStatus values. It fully discloses the irreversible financial impact and operational constraints beyond the annotations.

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

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

The description is long but well-structured with headers (When to Use, When NOT to Use, Returns, Error Handling). The critical warning about moving real funds and irreversibility is front-loaded. Every section adds necessary context; there is no filler or redundancy.

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

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

The description covers the full workflow: prerequisite quoting, human approval, execution semantics, status interpretation, error handling for expired quotes and 5xx/timeouts, and the next-step tool (binance_get_convert_order_status). With an output schema present and a thorough description, nothing an agent needs to call this tool safely 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 schema already provides a clear description for the sole parameter quote_id ('The `quoteId` returned by `binance_get_convert_quote`. Accepting it EXECUTES the conversion at the quoted ratio.'). The tool description does not add new parameter-level semantics beyond reinforcing the same information. With schema coverage high, a baseline 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 states a specific action ('Accept a convert quote and EXECUTE the conversion') with a clear resource and consequence ('moves real funds'). It also distinguishes itself from siblings like binance_get_convert_quote (for pricing) and binance_place_convert_limit_order (for non-current prices). The purpose is unambiguous.

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

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

The description includes explicit 'When to Use' and 'When NOT to Use' sections, naming the alternative tools and the conditions that select them. It also provides a prerequisite (price with binance_get_convert_quote first) and a kill-switch condition. No ambiguity remains about when to invoke 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?

Beyond the annotations, the description discloses the kill-switch requirement, idempotent effect, refusal behavior, and the fact that already-filled sub-orders cannot be undone. It also explains error semantics, including the ambiguous 5xx/timeout case and re-checking open orders. This is rich, truthful behavioral context that matches the annotations with no contradiction.

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

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

The description is long but every section earns its place: identity, endpoint, parameter rule, kill-switch, idempotence, use cases, return shape, examples, and error handling are all separated with clear headers and bolded lead-ins. The most critical information is front-loaded, and the structure makes it easy to scan.

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 destructive nature, auth requirements, ambiguity risk, and Binance-specific error codes, this description is complete. It covers return values, examples, preconditions, failure modes, and what the tool cannot do. An agent has enough information to invoke it correctly and interpret the result in all meaningful cases.

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

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

The description explains the two mutually exclusive identifiers, their relationship to the schema, the 32-character constraint on client_algo_id, and the local refusal when both are passed. It adds crucial semantic meaning beyond the schema fields, especially the 'exactly one' rule and why ambiguity is rejected on a destructive call.

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 specific verb and resource: 'Cancel a working spot TWAP algo order.' It also identifies the exact endpoint and distinguishes this from ordinary spot order cancellation by naming the alternative tool. An agent can tell exactly what this tool does and which order type it targets.

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

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

There is an explicit 'When to Use' section with concrete scenarios, and a 'When NOT to Use' section that names binance_cancel_order as the alternative for ordinary spot orders. It also advises checking binance_get_open_algo_orders first. This fully routes the agent to the correct tool and preconditions.

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

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

Annotations already signal destructive/non-read-only behavior, and the description adds meaningful operational context: the BINANCE_ALLOW_TRADING kill-switch, inclusion of OCO/OTO list legs, -2011 semantics, and the UNKNOWN outcome on 5xx/timeout. 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?

Front-loads the core behavior in the first line, then uses scannable sections for endpoint, usage, exclusions, returns, examples, and errors. Every section adds actionable information rather than filler.

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

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

Covers invocation, side effects, alternatives, return shape, example, and ambiguous failure outcomes. For a destructive cancel-all operation with an output schema and rich annotations, nothing an agent needs to call it correctly 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 schema covers the single symbol parameter, and the description reinforces it with a concrete example params = {'symbol': 'BTCUSDT'}. Since this is a one-parameter tool, the example plus the 'on one symbol' scope is sufficient compensation for the minimal prose about parameter formatting.

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

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

States an explicit verb and scope: 'Cancel EVERY open order on one symbol, including order-list legs.' It further identifies the exact REST endpoint and contrasts itself with the id-based cancel sibling, so an agent can distinguish it from binance_cancel_order and binance_cancel_order_list immediately.

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 dedicated 'When to Use' and 'When NOT to Use' sections with concrete scenarios, and names sibling alternatives binance_cancel_order and binance_get_open_orders. This is exactly the routing guidance needed.

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 goes well beyond the annotations by disclosing the kill-switch behavior tied to BINANCE_ALLOW_TRADING=1, the UNKNOWN cancellation status on 5xx/timeout, and the need to verify resting orders before retrying. This is valuable operational context that annotations alone do not provide.

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

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

The description is long but every section earns its place: use criteria, exclusions, return behavior, example, and error handling. It is front-loaded with the primary action and endpoint, then organized into scannable sections without repetition.

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

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

Given the destructive and signed nature of the operation, the description covers endpoint, authentication implication, use cases, exclusions, return payload, example, and error recovery. No information an agent needs to invoke this correctly 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?

Although the schema itself documents order_id, the tool description reinforces it with a concrete example and explains where the ID comes from indirectly through sibling tool references. For a single required parameter, this is sufficient, though the description could have explicitly restated the parameter's source.

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

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

The description states a specific action ('Cancel a resting convert limit order') and names the exact endpoint, making the tool's purpose unambiguous. It also implicitly distinguishes this convert-order cancellation from spot-order cancellation, which is reinforced in the When NOT to Use section.

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 has explicit 'When to Use' and 'When NOT to Use' sections. It names binance_cancel_order as the alternative for spot orders and clarifies that completed conversions cannot be undone, leaving no ambiguity about when this tool should be selected.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true), the description discloses the kill-switch behavior, the local rejection of passing both order_id and orig_client_order_id, the idempotent effect of a second cancel, the inability to undo fills, and the meaning of -2011 errors. It also clarifies that 5xx/timeouts leave cancel state UNKNOWN and advises verification. This substantially exceeds the annotation coverage.

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 tightly organized into labeled sections: core action, kill-switch, idempotency, when to use/not use, returns, examples, and error handling. Each section adds necessary operational knowledge, and the most essential usage constraint is front-loaded in the first sentence.

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

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

For a mutation tool with no output schema details needed (output schema is present), the description covers endpoint, signing, IP weight, parameter constraints, error semantics, failure ambiguity, and concrete examples. It leaves no significant gap an agent would need to resolve before calling 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?

Despite the schema property descriptions, the tool description adds critical semantics: exactly one identifier must be passed, both at once is rejected locally, and why that matters. It also explains cancel_restrictions as the safe guard against racing a fill and interprets -2011 in that context. Examples reinforce correct usage for both identifier variants.

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 specific verb and resource: 'Cancel one open spot order by id.' It also differentiates from siblings by explicitly naming binance_cancel_all_open_orders and binance_cancel_order_list as alternatives for different intents, leaving no ambiguity about what this tool does.

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 dedicated 'When to Use' and 'When NOT to Use' sections. It names specific sibling tools and the conditions that should route the agent to them, such as using binance_cancel_all_open_orders for cancelling all orders and binance_cancel_order_list for OCO/OTO legs.

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

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

Annotations already indicate destructive, idempotent, and non-read-only behavior, and the description adds substantial context: the BINANCE_ALLOW_TRADING=1 kill-switch, the -2011 idempotent no-op case, the risk of partial fills, and the unknown state after 5xx/timeout. This goes well beyond what annotations alone provide.

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

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

The description is long but highly structured with clear headers, bullets, examples, and error handling. The main purpose is front-loaded, and every section adds actionable information for a dangerous mutation tool without redundancy.

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

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

Covers the endpoint, authentication signature, server-side kill-switch, idempotency, error semantics, return shape, examples, and when to check the list status afterward. Combined with the output schema and annotations, an agent has everything needed to invoke this tool correctly and safely.

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

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

The description adds critical meaning not obvious from the schema: exactly one of order_list_id or list_client_order_id must be passed, both at once are rejected locally, and cancelling a leg also cancels the whole list. The example illustrates the optional new_client_order_id usage, though it does not exhaustively restate every parameter's constraints.

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

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

States a specific verb and resource: cancel an ENTIRE order list by id, explicitly noting every leg is affected. This clearly differentiates it from single-order cancel tools like binance_cancel_order and bulk-cancel binance_cancel_all_open_orders.

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

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

Includes explicit 'When to Use' and 'When NOT to Use' sections, naming alternatives such as binance_cancel_all_open_orders and binance_get_order_list. It also explains when cancelling one leg via binance_cancel_order makes this tool redundant, giving an agent actionable routing rules.

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 goes far beyond the annotations: it discloses the kill-switch requiring BINANCE_ALLOW_TRADING=1, explains STOP_ON_FAILURE vs ALLOW_FAILURE divergence, interprets HTTP 409 as the partial-success case, and warns that 5xx/timeouts leave both halves UNKNOWN. This richly supplements the destructiveHint and openWorldHint annotations without contradicting them.

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?

Long but disciplined: the core behavior is front-loaded, followed by kill-switch, mode semantics, HTTP 409 interpretation, use cases, exclusions, return values, and error handling in clearly separated sections. Every paragraph earns its place and the examples are highly illustrative for an agent.

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 high-complexity, destructive atomic operation this is complete: it explains partial success, ambiguous failure states, error codes, return shape, and when to check binance_get_open_orders after a 5xx. Nothing an agent needs to invoke and interpret this tool correctly 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 prose adds real meaning to the parameters: it explains how cancel_replace_mode changes the operation's outcome, clarifies the cancelResult/newOrderResult semantics, and gives two concrete example parameter sets showing cancel_order_id vs cancel_orig_client_order_id. The schema already documents individual fields thoroughly, so the description complements rather than merely repeats — though a dedicated sentence on the either-or cancel identifier requirement would push it to 5.

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

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

The description opens with a specific verb and resource — 'Cancel one order and place its replacement in a single request' — and names the exact endpoint. It explicitly differentiates itself from sibling tools such as binance_place_order, binance_cancel_order, and binance_cancel_order_list, leaving no ambiguity about scope.

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?

Dedicated 'When to Use' and 'When NOT to Use' sections give explicit conditions: reprice a resting order, roll a stop, and clearly route to alternative tools for fresh orders, pure cancels, or order-list legs. This is textbook usage 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 goes far beyond the annotations: it discloses irreversibility, lack of a cancel endpoint, service charges, the BINANCE_ALLOW_TRADING kill-switch, required Spot & Margin Trading permission, client-side batching limits, and the ambiguity of 5xx/timeout results. No contradiction with the annotations is apparent.

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 every section earns its place for a high-stakes irreversible operation. Bold headers, front-loaded warnings, examples, and error handling make the information scannable without redundancy.

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

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

The description covers prerequisites, kill-switch behavior, permissions, limits, return values, examples, and error handling. For a complex mutating operation with irreversible side effects, nothing an agent needs to safely call and verify the call 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?

Even though the signal says schema coverage is 0%, the description explains both parameters thoroughly: `assets` gets batching, preview, and query-key semantics, while `account_type` is clarified as SPOT or MARGIN with default behavior. Examples illustrate valid parameter shapes.

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

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

The description states a specific verb and resource: 'Convert small balances to BNB' via `POST /sapi/v1/asset/dust`. It also clearly distinguishes this from related tools by emphasizing irreversibility and pointing to alternate tools for meaningful trades and 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?

There is an explicit 'When to Use' and 'When NOT to Use' section. It names `binance_get_dust_convertible` as a required preview step, `binance_get_dust_log` for verifying past conversions, and the convert/spot tools as better alternatives for meaningful amounts.

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 far more than the annotations alone: it reveals that the tool is a heuristic workaround (no exact endpoint), enumerates the three underlying API calls and their weights, quantifies total cost, and states the base-asset matching blind spot. It also documents a testnet 404 and -2015 auth error. This is rich behavioral context beyond readOnly/idempotent hints.

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 its length is mostly justified by the tool's complexity — it communicates a workaround, cost, blind spots, and error states. It is well-structured with clear headings and front-loaded purpose. A few details (forum thread IDs, repeated mention of endpoint weights) could be trimmed without loss, so it is excellent but not maximally lean.

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?

Between the method explanation, cost estimate, blind spot, explicit when/when-not rules, return formats with JSON shape, concrete examples, and error handling, nothing an agent needs to decide whether and how to invoke this tool is missing. The output schema and annotations cover the remaining mechanical details. This is a complete briefing.

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 for the top-level 'params' wrapper is 0%, so the description bears a real burden, and it does explain extra_assets and quote_assets in context and names include_break in an example. However, it leaves full semantics of include_break and response_format to the nested schema, and there is no systematic parameter-by-parameter mapping in the description. It compensates substantially but not completely.

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 concrete result — 'work out which symbols this account plausibly traded' — and immediately states the core constraint: Binance provides no endpoint for traded pairs. It explicitly distinguishes itself from binance_get_all_my_trades by framing this as the discovery step before trade retrieval. The resource, verb, and relationship to siblings are all unambiguous.

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

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

The description contains dedicated 'When to Use' and 'When NOT to Use' sections. It names the precise alternative (binance_get_all_my_trades) and the condition for choosing this tool (unknown pairs, cost avoidance), and lists balance-reading siblings (binance_get_spot_account / binance_get_user_assets) as wrong for that job. This is explicit routing guidance, not just implication.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context beyond that: it specifies the endpoint (GET /sapi/v1/account/info), that it is SIGNED with IP weight 1, describes the return format (markdown vs json), and explains the -2015 error meaning. This is valuable but not exhaustive (e.g., no rate limit specifics), so a 4 is appropriate.

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 and concise: purpose, endpoint, usage guidance, returns, example, and error handling are each given a short labeled section. It is front-loaded with the core purpose and avoids any filler, making it easy for an 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?

For a simple read-only tool with an output schema (present per context), the description covers all necessary aspects: what it returns, how to invoke it (empty params), how to change output format, and how to interpret a common error. An agent can call this tool correctly without further inference.

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

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

Schema description coverage is 0% per context, so the description must compensate. It does: it explains the response_format parameter's effect (markdown vs raw JSON), provides an example of an empty params object, and clarifies the default behavior. This adds meaning beyond the schema's own (minimal) descriptions, which are actually present but not counted.

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

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

The description states a specific verb ('Report') and resource (account's VIP tier and product lines), and explicitly distinguishes itself from siblings by noting when NOT to use it for balances or trading permissions, naming binance_get_spot_account and binance_get_api_restrictions as alternatives. This makes the purpose unmistakable.

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 'When to Use' and 'When NOT to Use' sections, giving concrete conditions (checking VIP fee tier or product-line enablement) and exclusions (reading balances or trading permissions) with named alternatives. This is exactly the guidance an agent needs to route correctly.

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

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

The annotations already declare read-only and idempotent behavior, and the description adds substantial context: IP weight, Binance's one-month retention limit, local validation before the call, and the endpoint's unusual error envelope. It also explains that a non-200 `code` surfaces as an `Error:`, which is valuable beyond the annotations.

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

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

The description is long but densely informative, with clear section headers and front-loaded purpose. Every section earns its place: usage guidance, return format, window constraints, examples, and error handling all support correct invocation.

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 endpoint's complexity, the description is complete: it covers what is returned, how failures are signaled, input constraints, retention limits, and cost/rate implications. The presence of an output schema means the detailed return-value explanation is a bonus rather than a gap.

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

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

Schema description coverage is reported at 0%, so the description carries the full burden for parameter semantics. It fully compensates by explaining `type`, `limit`, `start_time`, `end_time`, and `response_format`, including defaults, the 30-day window rule, and local fail-fast validation. Concrete examples clarify how the parameters combine.

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

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

The description states a specific verb and resource: 'Return daily balance snapshots for the SPOT, MARGIN or FUTURES wallet.' It also distinguishes itself from a sibling by naming `binance_get_spot_account` as the tool for current balance.

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?

Contains explicit 'When to Use' and 'When NOT to Use' sections. It tells the agent to use this for historical balance reconstruction and specifically recommends `binance_get_spot_account` instead for live balances, citing cost and freshness.

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

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

Annotations already provide readOnly/idempotent hints, and the description adds rich behavioral context: the exact endpoint, SIGNED requirement, IP weight, what 'Normal' means, output format behavior, and error code -2015 semantics. This goes well beyond the structured 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 well-organized with clear sections, front-loads the purpose, and every section (When to Use, NOT to Use, Returns, Examples, Error Handling) adds value without redundancy. It is thorough yet focused.

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 status read with one optional parameter, the description includes endpoint details, auth requirements, rate-limit weight, return formats, error handling, and sibling differentiation. Nothing an agent needs to call it correctly 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 reported as 0%, so the description must compensate. It does so by explaining the response_format behavior in 'Returns' and providing two concrete example parameter sets, making the single parameter's effect clear even if the schema already has a short property description.

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 a specific verb and resource: 'Report whether the account is in good standing with Binance.' It also names two sibling tools in 'When NOT to Use' (binance_get_api_restrictions and binance_get_api_trading_status), making the boundary clear.

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 'When to Use' section gives concrete scenarios (pre-trading-run check, alongside API trading status when diagnosing rejects), and 'When NOT to Use' explicitly names alternatives for permission flags and trading locks. This leaves no ambiguity about tool 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds critical behavioral context beyond that: the 1-hour window limit with error code -1127, local rejection of combining `from_id` with time filters, the weight of 4, and the exact return formats (Markdown table vs JSON). This is rich, non-redundant disclosure.

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

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

The description is long but every section earns its place. It is front-loaded with the core purpose and the most critical constraint (1-hour window). Sections for use cases, returns, windows, examples, and error handling are clearly labeled and free of fluff. The structure makes it easy to scan, and no sentence is 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?

The tool has real complexity: multiple filtering modes, a hard time-window limit, weight/rate-limit implications, and two output formats. The description covers all of it, including error handling and examples. The output schema exists, but the description still explains return structure. Nothing an agent needs to invoke this correctly 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?

Although the schema itself has some property descriptions, the signal reports 0% coverage, so the description must carry the semantic burden. It does so thoroughly: it explains `from_id` for cursor walking, `start_time`/`end_time` for time windows, the 1-hour constraint on the window, the limit default and max, and the `response_format` options. It even provides example parameter sets. This adds far more meaning than the bare schema.

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

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

The description states the exact purpose: 'Fetch compressed/aggregate trades (same price, same taker order, same timestamp merged)' and names the endpoint and weight. It explicitly differentiates from sibling `binance_get_recent_trades` by noting that paging by `from_id` is unique to this tool. The verb, resource, and scope are all 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 description contains dedicated 'When to Use' and 'When NOT to Use' sections. It tells the agent exactly when to prefer this tool over `binance_get_recent_trades` (paging by id, cheap time-window reconstruction) and when not to (latest trades without filters). It also explains the 1-hour window constraint and how to slice longer ranges, leaving no inference to the agent.

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

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

Beyond the readOnlyHint/idempotentHint annotations, the description discloses the signed endpoint, IP weight, optional-filter semantics, absence of a maximum window, the 50-row render cap, pagination behavior, error code -2015 meaning, and testnet unavailability. This gives the agent far more behavioral context than annotations alone.

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 tightly organized with clearly labeled sections: endpoint, filters, when to use, when not to use, returns, pagination, examples, and error handling. Every section earns its place, and the core purpose is front-loaded in the first line.

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 paginated read-only endpoint with seven parameters, this description is essentially complete: it defines scope, alternatives, return shapes, pagination caveats, parameter formats, error meanings, and example calls. An agent has everything needed to select and invoke the tool correctly without additional inference.

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

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

Although the context signal reports 0% schema coverage, the nested schema actually contains property descriptions, and the tool description goes well beyond them: it clarifies every filter is optional, explains ISO-8601 vs epoch ms, documents page/page_size mapping and limits, and describes response_format effects. The description fully compensates for any schema ambiguity.

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 specific verb and resource: 'List finished spot TWAP algo orders — filled, cancelled or expired.' This immediately distinguishes it from open-order tools and clearly states scope. It also names the endpoint, further pinning down exactly what the tool does.

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 dedicated 'When to Use' and 'When NOT to Use' sections explicitly route agents to sibling tools: binance_get_open_algo_orders for working orders, binance_get_algo_sub_orders for per-order fills, and binance_get_all_orders for ordinary spot history. This is model guidance for when to invoke this tool versus alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, but the description adds substantial behavioral context beyond that: error handling for unknown algoId, the -2015 permission error, the testnet limitation, and the 50-row rendering quirk. This goes well beyond the structured 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 long but well-structured with clear headers (When to Use, Returns, Pagination, Examples, Error Handling). Every section carries information; there's minimal fluff. It could be slightly tightened but is far from verbose or 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?

Given the tool's complexity, the presence of an output schema, and rich annotations, the description covers all necessary call-time knowledge: use cases, exclusions, pagination nuances, error handling, and examples. Nothing an agent needs to invoke it correctly 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 schema already provides descriptions for each parameter (algo_id, page, page_size, response_format), so baseline is 3. The description adds meaningful semantics by explaining pagination mapping, the 50-row display limit, and when to use response_format='json'. This is value 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 opens with a specific verb+resource: 'List the individual orders a TWAP placed on the book, with fills and fees.' It explicitly differentiates from siblings by stating this is the only place to see slice-level fills and naming alternatives like binance_get_my_trades and binance_get_open_algo_orders. The purpose is unambiguous and distinct.

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 has dedicated 'When to Use' and 'When NOT to Use' sections that name exact sibling tools and conditions, such as finding algoId via binance_get_open_algo_orders and using binance_get_my_trades for symbol-wide trade lists. It leaves no ambiguity about when to select 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description goes far beyond by explaining the windowed walk (89-day windows, offset paging), deduplication by Binance id, the default since date and its rationale, cost per call, budget checking, resume cursor semantics, error handling (window halving, stop conditions), and exactly what truncated/no_progress mean. This rich behavioral detail is essential for correct invocation and is not available from annotations alone. 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 long but every sentence earns its place. It is structured with clear headers (When to Use, When NOT to Use, Returns, Pagination, Examples, Error Handling) and front-loaded with the core behavior. There is no fluff; each paragraph addresses a distinct aspect an agent must know. The length is proportional to the tool's complexity.

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 (windowed pagination, resume cursors, deduplication, error recovery), the description covers all operational concerns: what it returns, how to continue a partial run, how to interpret flags, and how errors are handled. It also notes the output schema's JSON structure and the markdown row limit. An agent has everything needed to invoke it correctly and interpret results without further guesswork.

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?

Even though the schema already describes each parameter (since, until, max_calls, resume_before, response_format), the description adds crucial semantics: the walk algorithm for since/until, the meaning and handling of resume_before (it replaces until), the default max_calls covering 15 years, and the response_format differences (markdown truncation vs full JSON structure). This goes well beyond the schema's basic field descriptions and clarifies inter-parameter behavior.

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 precise, specific statement: 'Every crypto deposit since `since` — the 90-day cap walked for you.' It clearly identifies the resource (crypto deposits) and the action (retrieve all since a date). It further distinguishes itself from siblings by explicitly naming alternatives (binance_get_deposit_history for recent windows, binance_get_all_withdrawals for withdrawals, binance_get_fiat_orders for fiat rails). No ambiguity remains about what this tool does.

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 contains dedicated 'When to Use' and 'When NOT to Use' sections. It lists concrete use cases ('Show me every deposit I have ever made', reconstructing cost basis) and explicit exclusions with the exact sibling tool to use instead. This is the gold standard for usage guidance—an agent is never left guessing when to pick 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?

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description adds substantial behavioral context beyond that: the pagination strategy (fromId, 1000 fills/page), the two budget brakes (max_weight and weight_ceiling), the cost model (20 IP weight per page per symbol), the cursor semantics, and the error-handling behavior (partial results returned with cursor on error). It also explains what happens with empty symbols and how to avoid re-checking them. This is rich, honest behavioral disclosure.

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

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

The description is long but every section earns its place: the endpoint gap rationale, the two brakes, the cost model, when-to-use, when-not-to-use, returns, pagination, examples, and error handling. It is well-structured with clear headers and front-loaded with the core purpose. It loses one point for length — some details (e.g., the dev.binance.vision thread numbers) are arguably noise for an agent selecting a tool — but the structure keeps it navigable.

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 (multi-symbol pagination, budget management, cursor resumption, discovery fallback), the description is remarkably complete. It covers cost, error handling, return format, pagination semantics, and examples. The output schema exists, so return values are further specified. An agent has everything needed to invoke this tool correctly and to decide when it is the right choice.

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

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

Schema description coverage is 0% per the context signal, but the description compensates thoroughly for the main parameters: symbols, cursor, max_weight, weight_ceiling are all explained with defaults and semantics. The discovery-related parameters (extra_assets, quote_assets, include_break) are only mentioned indirectly via 'same params as binance_discover_traded_symbols', which is a reasonable pointer but leaves some detail to the sibling. The response_format parameter is covered by the schema's own description. Overall, the description adds significant meaning 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 opens with a specific verb and resource: 'Collect every fill across every symbol this account traded' — the 'all my trades' answer. It explicitly distinguishes itself from binance_get_my_trades (single pair) and explains the workaround for Binance's missing endpoint. This is a model of purpose clarity.

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 has explicit 'When to Use' and 'When NOT to Use' sections. It names the alternative for single-pair queries (binance_get_my_trades), lists excluded transaction types (orders, deposits, withdrawals, converts, Pay/Card), and gives concrete use cases (tax/portfolio reconstruction, incremental top-ups). This is exactly the guidance an agent needs.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds valuable behavioral details: the IP weight (20 per call), the 24-hour window cap enforced locally with a readable error, the response format differences (markdown vs. JSON with truncation handling), and specific error codes (-1127, -1121). This goes well beyond annotations and prepares the agent for expected 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 well-structured with clear sections (purpose, when to use, returns, windows, examples, error handling) and every sentence contributes useful information. It is front-loaded with the core purpose and uses examples to clarify parameter usage, making it efficient despite its length.

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 all essential aspects: purpose, usage differentiation, behavior (IP weight, truncation, error handling), parameters (via examples and constraints), and output format. Given that an output schema exists, the description still adds critical context about local enforcement and display limits, making it fully complete for correct invocation.

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

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

Although the schema itself provides descriptions for each parameter, the tool description enhances semantics with concrete examples (symbol, start_time/end_time, order_id), explains the 24-hour constraint, and clarifies the pagination cursor via `from_allocation_id`. It does not explicitly mention the `limit` parameter, but the schema covers it; the description still adds meaningful context beyond schema basics.

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

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

The description clearly states 'List Smart Order Routing (SOR) allocations' — a specific verb and resource — and immediately distinguishes it from regular trade fills by naming the alternative `binance_get_my_trades`. This precise scoping leaves no ambiguity about what the tool does and how it differs from 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 includes explicit 'When to Use' and 'When NOT to Use' sections, directing agents to use this tool for SOR order fills and to use `binance_get_my_trades` for regular trades. It also mentions paging via `order_id`, providing clear guidance on invocation context.

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

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

Annotations already mark readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds substantial behavior: SIGNED endpoint, IP weight, no symbol filtering, local rejection of invalid parameter combinations, 24-hour window limit, error codes (-1127, -1128, -2015), and response rendering caps. This goes well beyond the annotations and structured 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 highly structured with clear sections (When to Use, When NOT to Use, Returns, Pagination, Windows, Examples, Error Handling). The core purpose is front-loaded, and every sentence adds operational value. No filler or tautology.

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

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

For a read-only historical listing tool with an output schema, the description is complete: it explains the return shape (markdown table with specific fields or raw JSON), the pagination model, local validation, error semantics, and the exact endpoint. An agent has everything needed to select and 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?

Even though the schema includes per-property descriptions, the tool description adds crucial semantics: how `from_id` pages forward ('pass the last orderListId you saw, plus one'), accepted time formats (epoch ms or ISO-8601), the 24-hour window restriction, the mutual exclusivity of `from_id` with time bounds, and the interpretation of `limit` vs. the 50-row rendering cap. Concrete examples further clarify parameter usage.

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

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

The opening line states a specific verb ('List'), a resource ('order lists'), a scope ('this account', 'account-wide', 'across symbols'), and includes all statuses ('working, completed and cancelled'). It also names the exact endpoint and differentiates itself from sibling tools like binance_get_open_order_lists and binance_get_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?

The 'When to Use' and 'When NOT to Use' sections are explicit, naming alternative tools (binance_get_open_order_lists, binance_get_order_list, binance_get_all_orders) and the conditions that select each. No inference is required from the agent.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds substantial behavioral context beyond them: the call is SIGNED with IP weight 20, the 24-hour window cap is validated locally, only 50 rows are rendered, and orders without fills are archived after 90 days. This gives an agent accurate expectations about rate limits, pagination, and data availability.

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 highly structured with clear sections, bullet lists, and concrete examples. Every section adds operational value: pagination, window rules, use cases, exclusions, and error handling. The critical 24-hour constraint is prominently highlighted, and the formatting makes the length scannable.

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 network-backed read tool with pagination, time windows, and auth requirements, the description covers endpoint details, local validation, limits, paging strategies, error codes, and example parameter sets. With an output schema present, no return-format explanation is needed, and nothing required to call the tool correctly 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?

Even though the nested schema has some parameter descriptions, the signal reports 0% schema description coverage, so the plain-language description carries the burden. It explains order_id cursor semantics ('orderId >= this'), start_time/end_time accepted formats (epoch ms or ISO-8601), the 24-hour span constraint, default behavior when both are omitted, and the effect of response_format, all beyond the schema fields.

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

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

The description states a specific verb and resource ('List a symbol's orders') and immediately clarifies scope: open, filled, cancelled and expired alike. It distinguishes itself from sibling tools like binance_get_open_orders and binance_get_my_trades, so an agent can select it correctly without opening schemas.

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

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

Dedicated 'When to Use' and 'When NOT to Use' sections explicitly route to alternatives: binance_get_open_orders for currently open orders and binance_get_my_trades for fills/fees/trade IDs. It also explains when to use order_id paging versus time windows, leaving no ambiguity.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false; the description adds substantial operational detail: UID weight 18,000 per call, 10 req/s limit, default max_calls=10 rationale, windowed walking with dedupe, resume_before cursor, no_progress/truncated flags, and error handling. It reinforces the read-only claim and never contradicts 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 lengthy but well-structured with clear section headings (rate limits, when to use, returns, pagination, examples, error handling). Every section serves a purpose for a complex windowed-walk tool, and the core purpose is front-loaded. No superfluous filler is present.

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 semantics, rate limits, defaults, return shape, pagination protocol, examples, and error handling. An output schema exists, so restating return fields is unnecessary; nonetheless, the description explains the top-level JSON keys and truncation behavior. Nothing an agent needs to invoke and recover from a partial walk 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?

Although the schema itself documents each parameter, the description goes beyond by explaining the operational significance: why max_calls defaults to 10 based on the UID budget, how resume_before is meant to be reused, and what no_progress/truncated semantically mean. This adds meaningful guidance beyond the schema's property descriptions.

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

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

The description opens with 'Every crypto withdrawal since `since` — the 90-day cap walked for you', clearly stating the tool's function and scope. It explicitly contrasts itself with binance_get_withdraw_history and binance_get_all_deposits, so an agent can distinguish it from siblings even without reading schemas.

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

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

Dedicated 'When to Use' and 'When NOT to Use' sections give concrete alternatives and conditions, such as using binance_get_withdraw_history for a single recent window and binance_get_all_deposits for deposits. It also states that making a withdrawal is impossible by design, leaving no ambiguity about misuse.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive, and the description adds meaningful context: the endpoint is SIGNED with IP weight 1, risky flags are marked with ⚠️, and error -2015 maps to missing Reading permission or non-allowlisted IP. 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 well-structured with short headed sections: core behavior, when to use, when not to use, returns, examples, and error handling. Every section adds actionable information without redundancy.

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

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

It covers the endpoint, authentication context, return format, error handling, usage boundaries, and an example call. For a tool with a single optional parameter, an agent has everything needed to select and invoke it correctly.

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

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

The only meaningful parameter, response_format, is already described in the schema, and the description reinforces it with 'raw JSON with response_format="json"' and an example params = {}. Schema coverage is listed as 0%, but the description compensates well for the one user-controlled parameter.

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

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

The description opens with a specific verb and object: 'Report the full permission flag set on the configured API key.' It also names the exact Binance endpoint and explicitly contrasts itself with binance_health_check, so an agent can distinguish this from sibling tools.

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

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

The description provides explicit 'When to Use' and 'When NOT to Use' sections. It names binance_health_check as the alternative for quick post-startup checks and explains that the sibling already calls this endpoint as part of a broader check.

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

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

Annotations already mark the tool read-only, idempotent, and non-destructive; the description adds the endpoint, SIGNED/auth requirement, IP weight, the abuse-prevention lock cooldown context, and the -2015 error meaning. This is exactly the kind of behavioral context that annotations do not provide, and it does not contradict them.

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 organized into clear labeled sections (purpose, when to use, when not to use, returns, examples, error handling) with no filler. Every sentence adds operational value, and the main purpose is front-loaded.

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

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

The description covers selection criteria, exact endpoint, authentication/error behavior, return format options, and example invocation. For a single-parameter read-only status tool, nothing needed for correct invocation is missing.

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

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

There is only one parameter (response_format), and the description demonstrates an empty params object plus the json override, while the schema supplies the enum/default details. Given the near-zero schema coverage signal, the description compensates well enough for the single optional parameter.

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

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

The first sentence gives a specific verb and resource: 'Report whether spot trading is locked and what triggered it.' It is further distinguished from sibling tools by naming binance_get_account_status and binance_get_api_restrictions as different checks, so an agent can select it correctly.

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 'When to Use' section states a concrete trigger condition (order placement failing for no filter/balance reason) and the 'When NOT to Use' section explicitly names the alternatives for general account status and key permission flags. This leaves no ambiguity about when this tool should be chosen over 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond that: the endpoint is SIGNED with IP weight 1, the response is a map keyed by asset (not a list), error -2015 indicates permission/IP issues, and an unknown asset returns an empty map rather than an error. It also reveals the HTTP client refuses withdrawal calls. This is rich, non-redundant disclosure.

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

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

The description is well-organized into clear sections (purpose, when to use/not use, returns, examples, error handling). It is front-loaded with the core purpose and uses bullet points effectively. Every sentence contributes to decision-making; there is no fluff or redundant text. The length is justified by the amount of useful information.

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

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

The description covers the return format (markdown table with specific columns, 50-asset cap, JSON raw option), error handling (-2015, empty map), usage boundaries, and provides concrete examples. It also references the output schema implicitly. Given the tool's complexity and the presence of an output schema, this description leaves almost nothing an agent needs to call it correctly.

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

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

The input schema already provides descriptions for `asset` and `response_format`. The tool description adds practical semantics: 'Omit for every asset Binance lists,' 'pass `asset` to narrow,' and clarifies the effect of `response_format="json"` (raw map). It doesn't fully explain every nuance (e.g., regex pattern for asset), but the schema covers that. This adds meaningful usage context without repeating 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 opens with a specific verb and resource: 'Report per-asset deposit/withdraw status, withdraw fee and minimum.' It explicitly names the endpoint and distinguishes itself from the sibling `binance_get_coin_config` by stating what it does not cover. This leaves no ambiguity about the tool's role.

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 has dedicated 'When to Use' and 'When NOT to Use' sections. It gives concrete conditions (checking suspension, reading fees) and explicitly names the alternative tool for per-network details. It even notes the server intentionally has no withdrawal tool, preventing misuse. This is exemplary 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?

Beyond the annotations (readOnlyHint, idempotentHint), the description discloses the API weight, the 180-day window cap with local validation, error code -2015 meaning, and the exact return format (markdown table capped at 50 rows). This adds substantial behavioral context that is not available from annotations alone.

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 (purpose, when to use, returns, windows, examples, error handling). It front-loads the primary action and then provides necessary details without unnecessary fluff. Every section earns its place.

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

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

The description covers the return format, window constraints, error handling, and usage examples. It also mentions the response_format option for raw JSON. Given the tool's moderate complexity and rich schema, this is a complete and self-sufficient description.

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 contains detailed descriptions for every parameter (asset, limit, start_time, end_time, response_format), so schema coverage is high. The description itself adds little about parameters beyond mentioning the 180-day constraint, which is also in the schema's start_time description. Thus, 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 the tool's function as listing asset distributions (airdrops, rebates, interest) and explicitly identifies the underlying API endpoint. It differentiates itself from siblings by naming specific alternatives like binance_get_my_trades and simple_earn tools, so an agent can easily distinguish its 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 provides explicit 'When to Use' and 'When NOT to Use' sections, naming exact alternatives and conditions. It tells the agent to use this for balance growth without trades and to use earn tools for Simple Earn, and binance_get_my_trades for trades. This is complete guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds substantial behavioral detail beyond that: the averaging window concept, the specific API endpoint and weight, the return formats (Markdown vs JSON), and the error handling for invalid symbols. This gives the agent a full picture of how the tool behaves.

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 headings: purpose, call, when to use, when not, returns, examples, and error handling. It front-loads the core purpose and uses bullet points for efficiency. Every sentence adds value, and there is no fluff or repetition.

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

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

Given the tool has an output schema (so return structure is documented elsewhere) and only one required parameter, the description is complete. It includes an example, explains the response_format's impact, and covers error handling. Nothing an agent needs to invoke the tool correctly 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 provides good descriptions for symbol and response_format, so the baseline is 3. The description adds a concrete example with symbol and explains the effect of response_format via the Returns section (Markdown vs JSON). While it does not explicitly name response_format as a parameter, the link is clear. This is a moderate enhancement over schema-only information.

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 specific verb and resource: 'Fetch the current average price over Binance's configured window (typically 5 min).' It clearly distinguishes this from the ticker-price tool by naming the sibling in the 'When NOT to Use' section, so an agent can immediately tell them apart without inspecting schemas.

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

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

The description provides an explicit 'When to Use' (smoothed reference price for MARKET order sanity checks) and 'When NOT to Use' (latest tick price, with the alternative tool named). This leaves no ambiguity about when to select this tool over 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable context beyond those: the exact API endpoint, weight costs per parameter combination, row cap (100), return format details, and a specific error code. It enriches the safety and operational picture without contradicting 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 well-organized with headings for purpose, use cases, returns, examples, and errors. Every sentence adds actionable information; no filler or repetition. The most critical information (what it fetches) is front-loaded, and the alternative tool is named early.

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 (multiple symbol modes, response formats, weight variations, error handling), the description covers endpoint, rate-limit weight, use-case boundaries, return structure, row limit, and error behavior. With annotations and an output schema also present, nothing an agent needs to call it correctly 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 schema already describes symbol, symbols, and response_format with mutual exclusivity and defaults. The description adds a concrete example (params = {'symbol': 'BTCUSDT'}) and explains the effect of response_format on output (Markdown vs JSON structure), which goes beyond the schema's terse 'Output format.' Since the schema carries most parameter documentation, a 4 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 states a precise verb-resource pair ('Fetch the best bid/ask price and quantity') with explicit scope (one, several, or all symbols) and distinguishes itself from binance_get_order_book by clarifying it provides top-of-book size without full depth. This leaves no ambiguity about the tool's function.

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?

Dedicated 'When to Use' and 'When NOT to Use' sections explicitly name the sibling binance_get_order_book as the alternative for multiple price levels, giving clear selection criteria. This fully covers when to invoke this tool versus others.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe-read profile is covered. The description adds valuable behavioral detail on top: the endpoint is SIGNED and costs IP weight 10; it takes no server-side filter, so the coin parameter is applied client-side; the response is capped at 50 coins in markdown but full JSON with response_format='json'; and unknown coins yield an empty result rather than an error. It also explains the -2015 error meaning (key lacking Reading permission or IP not allowlisted). This is rich, non-obvious behavior that an agent needs to call correctly.

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 efficiently organized with a bolded summary, a technical call line, a purpose paragraph, 'When to Use', 'When NOT to Use', Returns, Examples, and Error Handling. Every section earns its place, front-loads the most decision-relevant info (purpose and scope), and uses whitespace/headers to make scanning fast. There is no filler or repetition of 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?

Given the tool's moderate complexity (single param, clear output shape, annotations covering safety), the description is complete: it covers the endpoint, auth/rate-limit cost, data returned, client-side filtering, output format behavior, error handling, and examples. An output schema exists (per the context signal), so return-value structure is documented elsewhere; the description adds the human-meaningful context (what the fields mean for deposit/withdraw decisions). Nothing an agent needs to call and interpret this tool is missing.

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

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

Schema description coverage is 0%, and the only real parameter is `coin` (plus the standard `response_format`). The description compensates well: it explains that `coin` is applied client-side because the endpoint takes no filter, and that passing `coin` narrows the markdown cap; it also explains the `response_format='json'` behavior. However, it doesn't enumerate possible coin values or give format details beyond what the schema already states (e.g., the schema already defines response_format enum). A 4 is warranted because the description adds essential semantics the schema lacks.

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 crisp summary—'Per-coin deposit/withdraw switches, networks, fees and minimums'—and immediately identifies the exact endpoint, HTTP method, and signing requirement. It goes beyond a generic verb+resource by enumerating the actual data fields (depositEnable, withdrawFee, withdrawMin) that the tool exposes, which lets an agent know precisely what it will get. It is clearly distinguished from adjacent siblings (e.g., binance_get_deposit_address, binance_get_trade_fees) by stating what it is not.

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 contains explicit 'When to Use' and 'When NOT to Use' sections with concrete scenarios (e.g., before depositing to confirm depositEnable; to compare network fees for USDT on TRX vs ETH) and names specific alternatives (binance_get_deposit_address for addresses, binance_get_trade_fees for trading fees). It also gives a cost-based reason for calling once and reading multiple coins, which is operational guidance that helps an agent decide when the call is worth making.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses the API endpoint (GET /api/v3/account/commission), the IP weight (20), and error handling for codes -1121 and -2015. It also describes the return format and structure. This adds substantial behavioral context about rate limits and failure modes.

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 (purpose, API info, when to use, when not to use, returns, example, error handling). It front-loads the core purpose and then provides necessary details without redundancy. Every section earns its place.

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

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

The description includes all necessary information for an agent to call the tool correctly: the API endpoint, authentication context (SIGNED, USER_DATA), rate limit weight, example call, expected return structure, and error codes. Given the simple parameter set and existing annotations, nothing essential 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 schema descriptions for 'symbol' and 'response_format' are present, but the top-level 'params' has no description (coverage 0%). The description compensates with an example (params = {'symbol': 'BTCUSDT'}) and explains the return format, which clarifies how the parameters are used. It doesn't fully elaborate on response_format, but the schema's enum and default cover 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 first sentence clearly states the tool's purpose: 'Get the account's standard/special/tax commission rates for one symbol.' It uses a specific verb (get), identifies the resource (commission rates), and scopes it to a single symbol. It also distinguishes itself from siblings by naming binance_get_spot_account as the alternative for default rates.

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 explicit 'When to Use' and 'When NOT to Use' sections, providing concrete criteria (e.g., 'exact maker/taker/buyer/seller commission that will apply on a given symbol') and naming the alternative tool (binance_get_spot_account). This leaves no ambiguity for an agent selecting the right 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds valuable behavior beyond that: SIGNED endpoint, IP weight, client-side filtering, 100-row Markdown cap, the -1111 precision error, -2015 permission/IP errors, and testnet 404. 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?

Well-structured with clear sections, front-loaded purpose, and only functional details: endpoint, usage, examples, and error handling. Every sentence adds value or routes the agent away from mistakes.

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?

Covers endpoint, authentication/signing, rate weight, precision behavior, filtering, output cap, examples, and error codes. With a simple parameter set, strong annotations, and an output schema present, nothing critical 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?

Context reports 0% schema description coverage, so the description must compensate. It explains asset as a client-side filter with examples and clarifies what `fraction` means for amounts. `response_format` is not mentioned in the description, but the schema already describes it, so this is a minor gap.

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

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

States exactly what it does: shows the decimal precision (`fraction`) Convert accepts per asset. It also names the endpoint and explicitly differentiates itself from binance_get_convert_pairs, so an agent can select it without opening the schema.

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

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

Provides explicit When to Use (before binance_get_convert_quote, when a quote is rejected for precision) and When NOT to Use (pairs/min-max, pointing to binance_get_convert_pairs). It also includes examples and error-handling guidance, leaving no ambiguity about when to invoke 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?

Beyond the readOnlyHint and idempotentHint annotations, the description discloses critical execution behavior: no cursor/offset parameter, the moreData continuation mechanism, orderId-based deduplication, UID weight and rate budget, return-before-error behavior on mid-walk failures, the 50-row markdown cap, and specific Binance error codes. This is far more than the annotations alone provide and contains no contradiction.

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

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

Although long, the description is tightly organized into clear sections: mode summary, when to use, returns, pagination, examples, and error handling. It front-loads the core purpose and every section earns its place, given the tool's intricate pagination and two-mode parameterization. The examples compactly illustrate the valid parameter shapes.

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 is complete for an agent to call the tool correctly: it covers both modes, parameter interactions, continuation and resume semantics, response contents, failure behavior, rate-limit implications, and error interpretation. With an output schema also present, the description goes beyond what is strictly required without leaving meaningful 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?

The top-level schema has only one required 'params' property with 0% description coverage, so the description carries the full burden, and it delivers: start_time/end_time defaults and the 30-day rule, walk-mode semantics for since/until/resume_before, mutual exclusivity, accepted time formats, max_calls as a UID-weight budget, and limit behavior. It adds meaning well beyond the schema's property names.

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

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

The opening line, 'List past conversions, either for one <=30-day window or across a walked range,' names the exact verb, resource, and the two operational modes. The 'When NOT to Use' section further distinguishes it from binance_get_convert_order_status and binance_get_convert_open_limit_orders, so an agent can select it correctly without opening sibling schemas.

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

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

The description provides explicit 'When to Use' and 'When NOT to Use' sections with concrete conditions: reconciliation, finding an orderId, pulling more than 30 days via walk mode, and alternatives for checking a single recent conversion or resting limit orders. It also states that single-window and walk parameters are mutually exclusive and rejected locally, leaving no ambiguity about invocation.

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?

While annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, the description adds substantial behavioral context: the endpoint's weight (3000) and budget (180,000/min), a caution to poll sparingly, specific error codes (2015 for permissions, 429 for rate limit), and the exact return fields per row. This goes far beyond the annotations, giving the agent critical operational knowledge.

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, bullet points, and an example. Every sentence serves a purpose: purpose, usage guidance, return format, example, and error handling. The most critical info (what it does and when to use it) is front-loaded, and there is no redundant fluff. The length is justified by the richness of the content.

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

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

The tool is a read-only query with rate-limit implications, and the description covers all necessary aspects: purpose, usage scenarios, return format (fields per row), error handling, rate limit budget, and the example invocation. Even though an output schema exists, the description adds clarity about the return fields and markdown cap. Nothing an agent needs to decide whether to call this tool and interpret its results 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 schema has 0% description coverage for parameters, and the single parameter (params) is an object with response_format. The description compensates by providing an example 'params = {}' and noting 'Markdown display caps at 50 rows', which clarifies the markdown format behavior. It does not fully explain the json output variant, but the schema itself already has a description for response_format ('markdown or json output'), so the addition is marginal but still useful.

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 specific verb and resource: 'List the convert limit orders currently resting on the account.' It names the exact API endpoint and clearly distinguishes from siblings like binance_get_convert_history (completed conversions) and binance_get_open_orders (spot orders). The purpose is unambiguous and immediately actionable.

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 dedicated 'When to Use' and 'When NOT to Use' sections with concrete scenarios (e.g., before placing another order to avoid duplicates, after a timeout to check if the order rested). It explicitly names the alternative tools for completed conversions and spot orders, leaving no ambiguity about when this tool is appropriate.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable context beyond that: it notes the endpoint is SIGNED with UID weight 100, explains that unknown ids are rejected (not empty), and mentions error code -2015. It also discloses the return fields and that status is echoed verbatim. This is strong behavioral disclosure, though it doesn't elaborate on rate-limit handling or output formatting details, which are minor for a single-item read.

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, bullet points, and examples. It front-loads the core purpose, then efficiently covers usage, returns, examples, and errors. Each section is concise and to the point, with no redundant or filler content. The overall length is appropriate for the tool's complexity.

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-order status-check tool, the description covers everything an agent needs: when to use it, when not to, the endpoint and weight, the parameter constraint, expected returns, examples, and error handling. The presence of an output schema further reduces the need to explain return structures. Nothing critical is missing for correct invocation.

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

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

The description explicitly explains the exclusivity constraint: 'Exactly one of order_id / quote_id — Binance rejects both together.' It provides concrete examples for both parameter choices. The schema's own descriptions are minimal (just 'Convert order id (from...)'), so the description adds critical semantic value by clarifying the mutual exclusion and usage, which the schema does not fully convey.

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, specific statement: 'Check one conversion's status by orderId or by the quoteId it came from.' It names the resource (conversion status), the verb (check), and the two acceptable identifiers. It also distinguishes itself from siblings by explicitly stating it checks one conversion, not a list. This is precise 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 description includes dedicated 'When to Use' and 'When NOT to Use' sections. It tells the agent exactly when to call it (after acceptance, after timeout/5xx) and when to use alternatives (`binance_get_convert_history` for lists, `binance_get_convert_open_limit_orders` for resting orders). This explicit routing is excellent 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?

Beyond the annotations, the description discloses unauthenticated access, IP weight of 3000 out of a 12,000/min budget, the rarely-changing pair list with caching advice, the markdown 100-pair cap, JSON behavior, and 429 handling with `Retry-After`. This gives an agent important runtime behavior that annotations alone do not convey.

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 longer than average, but every section earns its place: purpose, endpoint, rate limit, caching, when-to-use, when-not-to-use, return behavior, examples, and error handling. It is organized with clear headers and front-loaded with the core purpose and critical rate information.

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

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

For a list tool with non-obvious rate limits and close sibling tools, the description covers all necessary context: start from the key endpoint, common usage cases, alternative tools, response shape, filter examples, and error handling. Nothing critical is missing for correct invocation.

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

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

Although the schema coverage signal is 0% for the top-level `params` wrapper, the description compensates thoroughly by explaining why `from_asset`/`to_asset` should be used, providing concrete examples, and describing how `response_format` affects output. This is exactly the semantic guidance an agent needs beyond the bare schema.

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

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

The description states a specific verb and resource: 'List the convertible asset pairs and their per-pair minimum/maximum amounts.' It clearly identifies the endpoint (`GET /sapi/v1/convert/exchangeInfo`) and differentiates from siblings by exactly naming what the tool is not for, such as `binance_get_convert_quote` and `binance_get_exchange_info`.

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 'When to Use' and 'When NOT to Use' sections give concrete scenarios: checking convertibility and amount bounds before quoting, or discovering available conversions via `from_asset`. It also names the alternative tools and the conditions under which they should be used instead.

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

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

Annotations provide readOnlyHint=true and destructiveHint=false, and the description is consistent, adding that it 'moves no funds' and nothing is converted until accepted. It goes well beyond the annotations by disclosing the UID weight 200 rate cost, that it works with the trading kill-switch off, that a quote is a short-lived non-idempotent reservation (not free, do not poll in a loop), and that the quoteId becomes void after validTimestamp — all of which align with openWorldHint=true and idempotentHint=false.

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?

Roughly 230 words is long, but every sentence earns its place given the reservation semantics, rate-weight, kill-switch nuance, and error codes that the description must carry at 0% schema coverage. It is front-loaded with the core purpose and behavioral headline, then uses clear labeled sections (When to Use, When NOT to Use, Returns, Examples, Error Handling) that make it scannable rather than a wall of prose.

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

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

The description covers the full call lifecycle: endpoint and signing, cost/weight, the allowlist quirk, the quote's expiry and invalidation, the accept step, return fields, example inputs, and the three most relevant Binance error codes. Even though an output schema exists (so return values needn't be explained), it describes the quoteId/ratio/inverseRatio/validTimestamp result anyway, making the tool callable correctly with zero prior Binance knowledge.

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

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

With schema description coverage reported at 0%, the description carries the parameter-semantics burden and largely succeeds: two full example param sets illustrate the exactly-one-of from_amount/to_amount decision and the valid_time format, and the Error Handling section ties failure codes to amount precision and pair limits. Minor gaps remain — wallet_type and response_format are not explained in the description text — but the core parameters an agent must get right are well covered.

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

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

The description opens with a specific verb+resource: 'Request a convert quote: a reserved ratio, valid for 10 s to 2 minutes', and names the exact endpoint `POST /sapi/v1/convert/getQuote`. It actively distinguishes itself from siblings — noting it is NOT for indicative prices (binance_get_ticker_price) and NOT for converting at unavailable prices (binance_place_convert_limit_order) — so an agent can separate it from the other convert/order tools without opening schemas.

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

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

Explicit 'When to Use' and 'When NOT to Use' sections name sibling tools and the conditions selecting them: binance_get_ticker_price for free indicative prices, binance_place_convert_limit_order for unavailable prices, and binance_accept_convert_quote as the mandatory second half of the flow. This leaves nothing to inference about when to invoke this tool versus any alternative.

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

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

The description discloses the exact API endpoint, authentication requirement (API key only, no signature), IP weight, output format details (markdown table capped at 50 rows, or raw JSON), and the meaning of error code -2015. These go well beyond the annotations, which already indicate a safe read-only, idempotent operation.

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, front-loaded purpose, and every section earning its place. It includes use cases, exclusions, return format, an example, and error handling without unnecessary fluff.

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 is complete for an agent to decide when and how to call this tool: it covers endpoint, auth, usage guidance, output format, example invocation, and error semantics. The output schema and annotations cover the remaining structured details, so nothing essential 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 schema already documents response_format with its enum and default, and the description references response_format='json' and shows params={} as an example. However, the description does not explicitly state the default output format or enumerate the allowed values, so it adds only moderate meaning beyond the schema. The low schema coverage signal means the description could have compensated more fully.

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 specific verb and resource: 'List symbols scheduled to be delisted, with their delisting date.' This clearly identifies what the tool does and the domain it operates in. It also differentiates from sibling tools by naming binance_get_exchange_info as the alternative for checking current trading status.

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 has explicit 'When to Use' and 'When NOT to Use' sections, giving concrete scenarios such as checking before placing an order and sweeping open positions. It names the specific alternative tool and the condition that should trigger its use, leaving no ambiguity.

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

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

Annotations already mark it read-only, idempotent, and non-destructive. The description adds critical behavioral context: omitting network returns default (not always desired), sending to wrong network loses funds, and error handling details like -2015. This goes well beyond the annotation safety profile, covering risk and failure modes.

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 longer but well-structured with clear sections: purpose, API call, warning, when-to-use/not-use, returns, examples, and error handling. It is front-loaded with the core purpose and each section earns its place, especially given the risk of fund loss. Slightly verbose but justified.

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 risk and multiple parameters, the description covers purpose, usage, warnings, return formats, examples, and error handling. It mentions key output fields and the response_format option. With an output schema present, it needn't detail every field. Nothing essential for correct invocation 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 high (each parameter has a description in the input schema), so baseline is 3. The description adds examples and clarifies the network omission behavior, but does not describe each parameter beyond what the schema already provides. It adds value through examples and risk warning, but not new 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 states a specific verb and resource: 'Get the deposit address for one coin on one network.' It explicitly names the API endpoint and differentiates from siblings by naming binance_get_deposit_addresses and binance_get_coin_config. This gives an agent unambiguous purpose and scope.

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 explicit 'When to Use' and 'When NOT to Use' sections, stating to use it before sending crypto into Binance and to avoid it for viewing all addresses or checking deposit enablement, with alternatives named. This leaves no inference for the agent.

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

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable context: it names the exact API endpoint, mentions SIGNED and IP weight, notes the row cap of 50, and explains the -2015 error meaning. This goes beyond annotations and enriches agent decision-making.

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 tightly organized with headings for use cases, returns, examples, and errors. It is front-loaded with the core purpose and contains no fluff. Every sentence adds 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?

Given the tool's complexity (multiple networks, output formats, error codes), the description covers purpose, usage, alternatives, return format, examples, and error handling. The existence of an output schema further reduces the need for return-value detail. Nothing essential 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 reported as 0%, so the description must compensate. It provides examples with coin and network, and mentions response_format in the Returns section, but does not explicitly define each parameter's purpose. Still, the examples and context imply usage well enough for an agent to construct correct calls.

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

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

The description states a specific action ('List every deposit address') with clear resource and scope ('for one coin, across networks'). It also explicitly differentiates from the sibling tool binance_get_deposit_address by noting the canonical-address alternative. This makes the purpose unmistakable.

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?

Includes explicit 'When to Use' and 'When NOT to Use' sections. The 'When NOT to Use' names the alternative tool and the exact condition (getting an address to deposit right now), leaving no ambiguity about 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description adds substantial behavioral context: it is SIGNED with IP weight 1, the 90-day window cap is enforced locally with a readable error, over-wide windows are rejected before the request, and -2015 is explained. It also documents pagination, response formats, and the expected 404 on spot testnet.

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 tightly organized with clear headings: endpoint, when to use, returns, pagination, windows, examples, and error handling. Every section adds operational knowledge an agent needs, and the most important constraint (one 90-day window) is front-loaded.

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

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

For a read-only API wrapper with rich annotations, an output schema, and a detailed input schema, the description covers everything needed to invoke it correctly: endpoint, window constraints, pagination, error codes, return shape, and example parameter sets. There are no major 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?

Even though the context signal reports low schema coverage, the description thoroughly explains the meaning and behavior of the window parameters, including start_time/end_time edge cases, offset paging, limit bounds, and response_format. The nested schema also has per-field descriptions, but the tool description goes beyond it with concrete examples and window-bracketing 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 opens with a specific verb and resource: 'List crypto deposits into the account for one window (up to 90 days).' It names the exact endpoint and differentiates itself from binance_get_all_deposits, binance_get_withdraw_history, and binance_get_fiat_orders, so an agent can distinguish it from sibling tools without inspecting schemas.

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

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

Contains explicit 'When to Use' and 'When NOT to Use' sections that name alternatives and the conditions that select them, such as full-history reconciliation via binance_get_all_deposits and fiat deposits via binance_get_fiat_orders. This leaves no ambiguity about when the tool should be chosen.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, but the description adds valuable context beyond that: it explains that Binance uses POST for a query, that the endpoint is on the read allowlist and works even with the trading kill-switch off, emphasizes that nothing is converted, and documents error semantics (empty details, -2015). This is far more than the annotations provide.

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

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

The description is structured with clear sections (When to Use, When NOT to Use, Returns, Examples, Error Handling) and the core purpose is front-loaded in the first sentence. It is longer than many, but every section adds operational value—especially the kill-switch note and error handling—so the length is justified.

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 (SIGNED endpoint, POST-as-query, dust eligibility nuances, two parameters with defaults, error codes), the description is complete. It covers purpose, usage, parameters through examples, return format, and error handling, and an output schema is present so the return-value details in the description are a bonus rather than a requirement.

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 describes the two parameters (account_type and response_format) with defaults, and the description reinforces this with concrete examples (params = {}, params = {"account_type": "MARGIN"}) and mentions response_format="json" in the Returns section. Though the contextual signal says schema description coverage is 0%, the description compensates with examples and usage nuance, so it exceeds the minimum.

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 specific verb and resource: 'Preview which small balances can be converted to BNB, and what they are worth.' It explicitly contrasts with sibling tools by stating 'Nothing is converted by this call' and points to binance_get_dust_log for already-completed conversions, making the distinction clear.

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 'When to Use' section says to call this tool immediately before binance_convert_dust_to_bnb, and the 'When NOT to Use' section names binance_get_dust_log for prior conversions. This is explicit, actionable guidance that leaves no ambiguity about tool 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?

Annotations already declare readOnlyHint and idempotentHint, and the description adds substantial behavioral context beyond them: the call is SIGNED with IP weight 1, Binance caps results at the last 100 records regardless of window, no records before 2020/12/01, and error -2015 indicates a permission or allowlist problem. This gives the agent actionable expectations about side effects and failure modes.

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 longer than average, but every section earns its place: purpose, endpoint, usage routing, return format, window caveats, examples, and error handling. It is front-loaded with the core action and uses clear headings so an agent can quickly extract the needed facts.

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

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

For a read-only list tool with annotations covering safety and idempotence, the description fully covers what the agent needs: when to use it, what it returns, how parameters behave, Binance's constraints, and the meaning of the main error code. Nothing essential is left to inference.

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

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

The schema already describes start_time, end_time, account_type, and response_format, and the description further clarifies that start_time/end_time are optional, that the 100-record cap overrides any window, and that response_format='json' returns the raw envelope. The examples ('params = {}' and a dated range) show realistic invocation shapes.

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 opens with a specific verb and resource: 'List past dust-to-BNB conversions, with the per-asset detail of each one.' It also names the exact Binance endpoint, so the tool's scope is unambiguous. The 'When NOT to Use' section explicitly distinguishes it from binance_get_dust_convertible and binance_convert_dust_to_bnb.

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 'When to Use' and 'When NOT to Use' sections that name sibling tools and the conditions that route to them. It also discloses Binance's hard limits (last 100 records, nothing before 2020-12-01), which materially affect when this tool is appropriate.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds value by disclosing the SIGNED/USER_DATA requirement, the 150 IP weight, the return format options, and specific error semantics (-2015 and all-zero amounts). 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.