binance-mcp

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

With no annotations provided, the description carries the full burden. It adds valuable behavioral context by noting 'This includes OCO orders' and rate limiting ('Weight(IP): 1'), but fails to disclose return value structure, error behavior when no orders exist, or explicitly flag this as a destructive/mutating operation requiring authentication.

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?

Information is front-loaded with the action and scope in the first clause. The prerequisite is clearly separated on its own line. No redundant or filler text; every sentence delivers specific operational value (scope, OCO inclusion, weight, prerequisites).

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 lack of output schema, the description adequately covers invocation requirements and scope (including OCO edge case). However, it should ideally describe the return payload (e.g., list of cancelled orders) since no output schema exists to document this.

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

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

Schema description coverage is 100%, with all 4 parameters (symbol, signature, timestamp, recvWindow) adequately documented. The description mentions 'Symbol' in the title but does not augment parameter semantics beyond what the schema already provides, warranting the baseline score for high-coverage schemas.

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

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

The description explicitly states 'Cancel all Open Orders on a Symbol' with the specific verb 'Cancel', resource 'Open Orders', and scope 'on a Symbol'. It clearly distinguishes itself from sibling tool 'delete_api_v3_order' (single order cancellation) by emphasizing 'all' and mentioning OCO order inclusion.

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 prerequisite guidance: 'First call exchange info or symbol listing to discover valid trading pairs'. However, it lacks explicit contrast with alternatives like 'delete_api_v3_order' for single-order cancellation scenarios, though the functional difference is inferable from the name.

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

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

With no annotations provided, the description carries the full burden. It discloses rate limiting ('Weight(IP): 1') and return structure (symbol, orderId fields), but lacks explicit disclosure of mutation semantics, idempotency guarantees, or error behaviors (e.g., what happens if the order is already filled).

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 appropriately front-loaded with the action and efficiently structured. The Returns information is slightly dense inline, and the prerequisite is clearly separated, though the formatting could be cleaner for optimal readability.

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

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

Given the tool has 8 parameters and no output schema, the description compensates by providing return fields and prerequisites. However, for a trading mutation operation, it lacks coverage of edge cases (e.g., partial fills, already-cancelled orders) and explicit safety warnings that would be expected without annotations.

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

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

While the input schema has 100% description coverage, the description adds crucial semantic constraint information: 'Either `orderId` or `origClientOrderId` must be sent.' This XOR relationship between parameters is not captured in the schema structure and represents valuable added context for correct invocation.

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

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

The description opens with 'Cancel Order (TRADE)' followed by 'Cancel an active order', providing a specific verb and resource. The requirement that 'Either `orderId` or `origClientOrderId` must be sent' clearly distinguishes this single-order cancellation from sibling bulk deletion tools like delete_api_v3_open_orders.

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

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

The description includes an explicit PREREQUISITE section stating to first call exchange info to discover valid trading pairs, which provides clear workflow context. However, it does not explicitly contrast when to use this tool versus alternatives like delete_api_v3_order_list or delete_api_v3_open_orders.

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

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

With no annotations provided, the description carries the full burden. It successfully discloses rate limiting ('Weight(IP): 1'), side effects (leg cancellation triggers full cancellation), and return structure (orderListId, contingencyType fields). Missing only explicit auth prerequisites or error 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?

Information is front-loaded with the action, but the text is a single run-on sentence with internal metadata leakage ('[DISCOVERY]'). While information-dense, the lack of punctuation and structure hinders readability. Every sentence (fragment) earns its place, but formatting is poor.

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 7-parameter trading operation with no annotations and no structured output schema, the description adequately compensates by documenting the return object structure, rate limit weight, and behavioral side effects. Only minor gaps remain regarding error handling or explicit permission requirements.

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

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

Schema description coverage is 100%, providing descriptions for all 7 parameters (symbol, signature, orderListId, etc.). The description adds no additional parameter-specific semantics beyond the schema, meeting the baseline for high-coverage schemas.

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 explicitly states 'Cancel OCO (TRADE)' and 'Cancel an entire Order List', providing a specific verb and resource. It clearly distinguishes from sibling tool delete_api_v3_order (single order cancellation) by specifying OCO/list 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?

Provides behavioral context that 'Canceling an individual leg will cancel the entire OCO', implying the tool operates on the whole list. However, it lacks explicit guidance on when to choose this over delete_api_v3_order or delete_sapi_v1_margin_order_list.

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

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

With no annotations provided, the description carries full burden but only adds the rate limit 'Weight: 2' as behavioral context. It fails to disclose that this is a destructive operation (though implied by 'delete' in the name), whether the operation is idempotent, what happens to active WebSocket connections, or authentication requirements.

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 appropriately brief (two clauses) and front-loaded with the critical action and resource. Minor redundancy exists between 'Close a ListenKey' and 'Close out a user data stream'. The 'Weight: 2' appendage is slightly disjointed but provides useful implementation context without excessive bloat.

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

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

Given the tool's low complexity (single parameter, no nested objects, no output schema), the description provides the minimum viable context: the action, target resource, and rate limit cost. However, it lacks explanation of success indicators or side effects (e.g., 'returns empty object on success' or 'terminates all active connections using this key'), which would be expected for a complete destructive operation 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?

Schema coverage is 100% with the 'listenKey' parameter fully documented as 'User websocket listen key' with examples. The description mentions 'ListenKey' in the text, reinforcing the parameter's purpose, but adds no additional semantic context (e.g., format constraints, how to obtain the key) beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states the action ('Close') and resource ('ListenKey'/'USER_STREAM'), identifying this as a user data stream termination tool. It implicitly distinguishes from sibling margin/isolated variants (delete_sapi_v1_user_data_stream_isolated) by specifying USER_STREAM, though it could explicitly clarify this is for Spot API v3 versus other versions.

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

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

No guidance provided on when to use this tool versus the sapi_v1 variants (delete_sapi_v1_user_data_stream) or prerequisites (e.g., that a stream must first be created via post_api_v3_user_data_stream). The description only states what the tool does, not when to select it.

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

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

With no annotations provided, the description carries the full burden. It successfully discloses: rate limits ('Weight(IP): 1'), base URL, permission requirements, and return structure ('Returns: { algoId: number, success: boolean... }'). It notes the operation only works on 'active' orders.

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?

Information-dense with no wasted words. The content is front-loaded with the action statement. Minor deduction for the slightly cluttered dash-bullet formatting within a single string, though all included details (URL, weight, returns) are valuable.

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 lack of annotations and structured output schema, the description compensates well by including the return object structure, rate limiting info, and API permission requirements. It adequately covers the behavioral contract for a deletion operation.

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

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

Schema description coverage is 100%, establishing a baseline of 3. The description adds no additional parameter semantics beyond the schema (e.g., it doesn't explain signature generation or that algoId refers to the order being cancelled), but meets the baseline expectation.

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 'Cancel Algo Order(TRADE)' providing a specific verb (Cancel) and resource (Algo Order). The tool name includes 'futures' and the description mentions 'Futures Trading Permission', effectively distinguishing it from the sibling 'delete_sapi_v1_algo_spot_order'.

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

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

The description states the prerequisite: 'You need to enable Futures Trading Permission for the api key'. However, it lacks explicit guidance on when to use this versus the spot algo cancellation tool or regular order cancellation endpoints.

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

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

No annotations are provided, so the description carries the full burden. It successfully documents rate limiting ('Weight(IP): 1') and discloses the return structure ('Returns: { algoId: number, success: boolean, code: number, ... }') which compensates for the lack of output schema. However, it omits details on error conditions or side effects (e.g., handling of partially filled orders).

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

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

The description is compact and front-loaded with the action ('Cancel Algo Order'), packing rate limit and return value information into a single sentence efficiently. While dense, every clause provides distinct value 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?

Given the lack of annotations and output schema, the description adequately compensates by documenting return values and rate limits. It correctly identifies the specific order type (TWAP) being operated on. It could be improved by mentioning that the algoId must be sourced from open orders queries, but is otherwise complete for a cancellation endpoint.

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 100% schema description coverage, the structured schema already defines all 4 parameters (algoId, timestamp, signature, recvWindow) adequately. The description does not add additional semantic context for parameters (e.g., explaining that algoId comes from open orders), meeting the baseline expectation for high-coverage schemas.

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

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

The description explicitly states 'Cancel Algo Order' and specifies 'Cancel an open TWAP order,' providing a specific verb (Cancel), resource (TWAP order), and scope. It distinguishes from the sibling delete_sapi_v1_algo_futures_order through the 'spot' path segment and from regular order cancellation tools (delete_api_v3_order) by specifying 'TWAP' and 'Algo.'

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

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

The phrase 'Cancel an open TWAP order' implies usage context (when you have an open TWAP algo order to cancel), but lacks explicit guidance on prerequisites (e.g., obtaining algoId from get_sapi_v1_algo_spot_open_orders) or explicit differentiation from delete_sapi_v1_algo_futures_order beyond the path naming.

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

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

No annotations provided, so description carries full burden. It successfully discloses rate limit 'Weight(UID): 300', return format '{ success: boolean, symbol: string }', and business constraint 'once every 24 hours'. Minor gap: does not explain consequences of disabling (e.g., impact on open positions or ability to re-enable).

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?

Excellent information density with zero waste. Structure flows logically: action/title → core description → rate limit → return type → prerequisite. Every sentence provides actionable information (TRADE classification, weight, return shape, prerequisite workflow).

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 medium complexity (margin operations require understanding valid pairs), the description is nearly complete. It compensates for missing output_schema by documenting the return format inline. Includes rate limiting and prerequisites. Would achieve 5 with explicit mention of whether open positions must be closed before disabling or re-enablement capabilities.

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

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

Schema description coverage is 100% (all 4 parameters have descriptions with examples where appropriate). The description mentions 'for a specific symbol' which aligns with the symbol parameter, but adds no additional semantic detail beyond the comprehensive schema. Baseline 3 is appropriate when schema does heavy lifting.

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

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

Excellent specificity with clear verb 'Disable', resource 'Isolated Margin Account', and scope 'for a specific symbol'. The (TRADE) tag and 'Disable' action clearly distinguish this from siblings like post_sapi_v1_margin_isolated_account (enable/create) and get_sapi_v1_margin_isolated_account (query).

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?

Strong prerequisite guidance explicitly stating to 'First call exchange info or symbol listing to discover valid trading pairs'. Includes important constraint 'deactivated once every 24 hours'. Lacks explicit naming of alternative tools (e.g., the POST version to enable), but the action verb provides clear implied contrast.

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

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

With no annotations provided, the description must carry the full burden. It discloses rate limiting ('Weight(IP): 1') and scope details ('includes OCO orders'), but lacks critical safety information for a destructive operation: no mention of irreversibility, what happens when no orders exist, or the response format/confirmation structure.

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

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

The description is appropriately dense and front-loaded with the operation type and scope. The prerequisite is clearly separated. Minor formatting irregularities (em-dash followed by hyphens) slightly detract from optimal structure, but every sentence provides distinct value 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?

For a destructive financial operation with 5 parameters and no output schema or annotations, the description covers the core operation, prerequisites, and rate limits, but leaves significant gaps: no description of success/failure responses, no behavioral details for edge cases (invalid symbol, empty order book), and no authentication context despite the signature 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?

Schema description coverage is 100%, establishing a baseline of 3. The description adds context that this operates on a 'symbol' for a 'margin account,' which supports understanding the isIsolated parameter, but does not elaborate on parameter syntax, signature generation, or timestamp formatting beyond the schema definitions.

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

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

The description explicitly states 'Cancels all active orders on a symbol for margin account,' specifying the verb (cancel), resource (all active/OCO orders), and scope (margin account, specific symbol). It distinguishes from siblings like delete_api_v3_open_orders (spot) and delete_sapi_v1_margin_order (single order) by emphasizing 'Margin Account' and 'all.'

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 prerequisite: 'First call exchange info or symbol listing to discover valid trading pairs, then query market data.' This gives clear sequencing guidance. However, it lacks explicit guidance on when to prefer this over single-order cancellation (delete_sapi_v1_margin_order) or spot cancellation (delete_api_v3_open_orders), though the scope is implied.

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

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

With no annotations provided, the description carries the full burden. It successfully discloses the rate limit 'Weight(IP): 10' and provides a partial output structure 'Returns: { symbol: string, ... }' despite no formal output schema existing. It notes the '(TRADE)' permission level. It could improve by mentioning error conditions or whether cancellation is immediate.

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 structured with a clear header, constraint statement, weight/return information, and a dedicated PREREQUISITE section. Information density is high with minimal waste. The return type clause is slightly compressed but still readable.

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

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

For an 8-parameter mutation tool with no annotations and no output schema, the description provides adequate context: it specifies the return structure, rate limits, prerequisites, and scope (margin vs spot). It appropriately compensates for the missing structured metadata.

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

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

While the input schema has 100% description coverage (baseline 3), the description adds crucial semantic information: the XOR constraint that 'Either orderId or origClientOrderId must be sent.' This is vital because neither parameter is marked as required in the schema individually, yet one is mandatory for the operation to succeed.

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

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

The description explicitly states 'Cancel an active order for margin account,' providing a specific verb and resource. It clearly distinguishes this from sibling spot order tools (e.g., delete_api_v3_order) by explicitly mentioning 'margin account' and from bulk operations like delete_sapi_v1_margin_open_orders by specifying 'active order' (singular).

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 PREREQUISITE section explicitly states to 'First call exchange info or symbol listing to discover valid trading pairs,' providing clear prerequisite guidance. It also notes the constraint that 'Either orderId or origClientOrderId must be sent.' However, it does not explicitly name sibling alternatives (e.g., when to use delete_api_v3_order for spot vs margin).

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

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

With no annotations provided, the description carries full burden and successfully discloses rate limiting ('Weight(UID): 1'), return structure preview ('Returns: { orderListId... }'), and side effects (cascading cancellation of OCO legs).

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?

Information-dense and front-loaded with the action, but structurally cluttered with metadata tags ('[DISCOVERY]', 'TRADE', 'Weight(UID)') and uses hyphen separators rather than clean sentences, reducing readability.

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

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

Appropriately complete for an 8-parameter mutation tool with no output schema; compensates by documenting return values, rate limits, and domain-specific OCO behavior that would otherwise be unknown to the agent.

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?

While input schema has 100% coverage, the description adds essential semantic logic not captured in the schema structure: the conditional requirement that either orderListId or listClientOrderId must be provided, rather than both being optional.

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

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

The description explicitly states 'Cancel an entire Order List for a margin account' with specific domain context 'OCO' (One-Cancels-Other), clearly distinguishing it from sibling tools like delete_sapi_v1_margin_order (single orders) and delete_api_v3_order_list (spot trading).

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 clear usage constraints including the critical requirement that 'Either `orderListId` or `listClientOrderId` must be provided' and notes the cascading behavior that 'Canceling an individual leg will cancel the entire OCO'. Lacks explicit comparison to alternative deletion tools.

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

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

No annotations provided, so description carries full burden. It discloses rate limit weight (3000) and return structure (ipRestrict, ipList, updateTime), but lacks safety context for the destructive operation (e.g., irreversibility, what happens if IP not found).

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?

Single sentence is efficient but information-dense. Weight and return value are appended with dashes, making it slightly cluttered. All sentences earn their place, though structure could be clearer.

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

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

Adequate for a 7-parameter deletion tool. Description compensates for missing output schema by documenting return fields. Lacks explicit authentication/authorization details beyond 'For Master Account' and 'signature' parameter.

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

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

Schema description coverage is 100%, establishing baseline 3. The description adds no semantic detail beyond the schema (e.g., no format guidance for signature, no clarification of ipAddress 'add' phrasing).

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?

Clear verb (Delete) and resource (IP List for Sub-account API Key) with master account scope. Distinguishes from sibling GET/POST IP restriction tools. However, ambiguous whether it removes specific IPs or clears the entire list.

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

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

No guidance on when to use versus alternatives, prerequisites, or preconditions (e.g., checking current IP list before deletion).

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

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

With no annotations provided, the description carries the full burden. It adds valuable rate-limiting context ('Weight: 1') but omits authentication requirements, error conditions (e.g., invalid/expired key), and whether the closure is permanent or reversible.

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

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

The description is front-loaded and brief. However, 'Close a ListenKey' and 'Close out a user data stream' are redundant phrases stating the same action. The 'Weight: 1' suffix is concise technical metadata.

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-parameter delete operation with no output schema, the description adequately covers the core action and rate limit cost. However, it lacks critical context regarding which trading context this applies to (spot vs. isolated margin) compared to similar sibling tools.

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

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

The input schema has 100% description coverage, establishing a baseline of 3. The description mentions 'ListenKey' which aligns with the parameter name, but adds no additional semantic detail regarding format requirements or validation rules beyond the schema's example.

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

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

The description clearly states the action ('Close') and resource ('ListenKey'/'user data stream'), and includes the 'USER_STREAM' identifier to distinguish from order deletion siblings. However, it fails to differentiate from similar siblings like 'delete_api_v3_user_data_stream' or 'delete_sapi_v1_user_data_stream_isolated'.

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

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

No guidance is provided on when to use this tool versus the isolated margin variant or API v3 variant. No prerequisites (e.g., having obtained the listenKey from a POST request) are mentioned, and no alternatives are suggested.

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

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

With no annotations provided, the description carries the full burden. It provides useful rate-limiting information ('Weight: 1') and clarifies this terminates a resource. However, it lacks details on side effects (e.g., whether existing websocket connections are immediately severed, if the operation is idempotent, or authentication requirements).

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

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

Two short sentences. Slight redundancy between 'Close a ListenKey' and 'Close out a user data stream,' but the inclusion of technical metadata (Weight) is efficiently appended. Front-loaded with the core action.

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-parameter deletion tool without output schema, the description covers the essential operation. However, given the 'isolated' context implied by the tool name (isolated margin), the description is incomplete by failing to clarify this specific domain, which is critical for correct tool selection among the 10+ user data stream tools.

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

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

Schema coverage is 100%, providing a baseline of 3. The description mentions 'ListenKey' which maps to the parameter name, but adds no additional semantic context (such as where to obtain the key or that it is mandatory) beyond what the schema already provides ('User websocket listen key').

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

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

The description clearly states the action ('Close', 'Close out') and resource ('ListenKey', 'user data stream'), including the specific stream type 'USER_STREAM' in parentheses. However, it fails to distinguish from the sibling tool 'delete_sapi_v1_user_data_stream' (non-isolated version), leaving ambiguity about which margin context this applies to despite the 'isolated' in the tool name.

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

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

No guidance provided on when to use this tool versus alternatives (e.g., the non-isolated version), nor any prerequisites mentioned. The description does not indicate that this should be called when disconnecting from a websocket or cleaning up resources.

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

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

Without annotations, the description carries the full burden. It provides the rate limit weight (20) and partial return structure, which is valuable. However, it lacks explicit disclosure of authentication requirements, read-only safety, or error conditions beyond the implicit USER_DATA classification.

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 information-dense and front-loaded with no wasted words. The structure 'Category — Action. Constraint. Returns: {schema}' is efficient, though the 'Returns' clause is slightly cramped and uses '...' truncation.

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

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

Given no output schema exists, the description partially compensates by listing key return fields (commissions). However, it truncates with '...' leaving the full response shape ambiguous. For a critical account endpoint, this is adequate but not comprehensive.

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 100% schema description coverage, the baseline score applies. The description does not add semantic context beyond the schema (e.g., it doesn't explain that 'signature' requires HMAC-SHA256 or that 'recvWindow' prevents replay attacks), but the schema is self-sufficient.

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

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

The description clearly states it retrieves 'current account information' and specifies key return fields (makerCommission, takerCommission, buyerCommission), which helps distinguish it from sibling account endpoints like get_sapi_v1_account_status or get_sapi_v1_account_snapshot. The '(USER_DATA)' tag clarifies the permission 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?

No guidance is provided on when to use this tool versus the many sibling account information endpoints (e.g., get_sapi_v1_account_info, get_sapi_v1_account_snapshot). The agent cannot determine selection criteria or prerequisites from the description alone.

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

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

With no annotations provided, description carries the burden. It discloses rate limit ('Weight: 20') and return structure via inline JSON, which adds value. However, it fails to explicitly state this requires authentication (despite USER_DATA tag), is read-only, or mention error conditions/idempotency.

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?

Information-dense without redundancy. Front-loads purpose, includes rate limit weight, return structure, and prerequisites efficiently. The inline JSON return example is slightly dense but functionally valuable given lack of output schema.

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

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

Lacking formal output schema, the description manually documents the return structure including nested commission objects (standardCommission, taxCommission). Prerequisites are documented. Sufficient for a 3-parameter authenticated read operation.

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

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

Schema coverage is 100% with all 3 parameters (symbol, timestamp, signature) fully described. The description adds no additional parameter context beyond the schema, warranting the baseline score of 3 for complete schema coverage.

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

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

Description opens with specific verb 'Query' and resource 'Commission Rates', clearly identifying this as a commission retrieval tool. The '(USER_DATA)' tag and distinction from trading/order management siblings (delete_*, post_*order*) makes its scope 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?

Provides explicit PREREQUISITE workflow: 'First call exchange info or symbol listing to discover valid trading pairs, then query market data.' This establishes clear sequencing. However, lacks explicit 'when not to use' guidance versus similar account info tools like get_api_v3_account.

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

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

No annotations provided, yet description carries substantial burden effectively. Discloses aggregation algorithm, default temporal behavior ('most recent aggregate trades'), rate limiting ('Weight(IP): 2'), and critical data quality indicators (invalid trade markers: p='0', q='0', f=-1, l=-1). Missing: explicit auth requirements or pagination behavior beyond the limit parameter.

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?

Information-dense without waste. Uses structural markers (dashes for list items, 'PREREQUISITE:' for workflow) effectively. Technical details (invalid trade field values) are essential for correct interpretation. Slightly verbose format but every clause serves agent decision-making.

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

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

For a 5-parameter market data endpoint with no output schema, description adequately covers input behavior and partially documents output structure (via invalid trade field explanations). Lacks explicit return type documentation, but the invalid marker explanation (p, q, f, l fields) provides partial output schema context. Sufficient 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?

Schema coverage is 100%, establishing baseline 3. Description adds valuable interaction logic: explaining that fromId, startTime, and endTime are optional and that omitting all three returns the most recent trades. This temporal filtering context exceeds raw schema definitions.

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?

Excellent specificity: 'Get compressed, aggregate trades' clearly defines the action and resource. Explicitly distinguishes from regular trades by explaining the aggregation logic ('Trades that fill at the time, from the same order, with the same price will have the quantity aggregated'), making it clear this differs from sibling get_api_v3_trades which returns individual trades.

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?

Strong prerequisite guidance ('First call exchange info or symbol listing to discover valid trading pairs') establishes necessary workflow. Explains default behavior when temporal parameters are omitted. Minor gap: doesn't explicitly contrast when to choose this over get_api_v3_trades or get_api_v3_historical_trades, though the aggregation focus implies use case.

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

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

Without annotations, the description carries the full burden. It discloses the rate limit weight (Weight(IP): 20) and security context (USER_DATA), but lacks details on pagination behavior, data retention limits, or what fields are returned in the response.

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 mixes metadata tags ([DISCOVERY], USER_DATA, Weight(IP)) with functional description in a single sentence. While brief, the formatting is cluttered and front-loading the '[DISCOVERY]' tag reduces immediate clarity.

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 7 parameters and no output schema, the description adequately identifies the OCO-specific resource but lacks explanation of return structure, pagination, or the relationship between startTime/endTime parameters. It meets minimum viability but leaves gaps for a data retrieval tool.

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

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

The input schema has 100% description coverage, establishing a baseline score of 3. The description mentions filtering 'based on provided optional parameters' but adds no semantic meaning beyond what the schema already documents for the 7 parameters.

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 identifies the tool retrieves OCO (One Cancels Other) orders specifically, distinguishing it from generic order queries. However, it does not differentiate from similar sibling endpoints like 'get_api_v3_order_list' or 'get_api_v3_open_order_list'.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions 'USER_DATA' implying authentication is required, but does not state when to query 'all' OCOs versus 'open' OCOs (get_api_v3_open_order_list) or specific order lists.

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

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

With no annotations, the description carries the full burden and delivers: explains pagination behavior ('orders >= that orderId' vs 'most recent'), warns about data availability ('cummulativeQuoteQty will be < 0'), and notes the USER_DATA security context. Missing explicit read-only declaration.

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?

Information-dense with no wasted sentences. Every line serves a purpose: endpoint identification, core function, pagination logic, data caveats, parameter constraints, rate limits, and prerequisites. Minor formatting quirks ('.. -' bullets) don't significantly impede readability.

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

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

For an 8-parameter tool with no output schema and no annotations, the description covers input behavior and prerequisites well. However, it lacks any description of the return structure or response format, which would help an agent understand what data structure to expect back.

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 has 100% description coverage, establishing a baseline of 3. The description adds value by explaining the logical relationship between orderId and time-based parameters, but doesn't need to compensate for missing schema documentation.

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 'Get all account orders; active, canceled, or filled' with specific verb and resource. It distinguishes itself from sibling get_api_v3_open_orders by explicitly mentioning all order statuses (active, canceled, filled), making the scope 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?

Provides explicit prerequisite ('First call exchange info or symbol listing'), explains parameter dependencies ('If startTime and/or endTime provided, orderId is not required'), and includes rate limiting info ('Weight(IP): 20'). Could be improved by explicitly contrasting when to use get_api_v3_open_orders 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?

No annotations are provided, so the description carries the full burden. It adds valuable behavioral context by documenting 'Weight(IP): 2' for rate limiting and the return structure '{ mins: number, price: string, closeTime: number }'. However, it omits safety profile (read-only status) and authentication requirements that annotations would typically 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 appropriately sized and front-loaded with the purpose ('Current Average Price'). Information is dense with no wasted words, though the line break before PREREQUISITE creates slight structural fragmentation.

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

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

Despite having no output schema, the description documents the return object structure with field types. Combined with the rate limit weight and usage prerequisite, this provides sufficient context for a single-parameter read operation.

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

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

With 100% schema description coverage ('Trading symbol, e.g. BNBUSDT'), the schema fully documents the single parameter. The description references 'for a symbol' but does not add semantic meaning beyond the schema's definition, meeting the baseline for high-coverage schemas.

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 'Current average price for a symbol' with specific verb and resource. It distinguishes from sibling tools like get_api_v3_ticker_price or get_api_v3_ticker_24hr by specifying 'Average Price' rather than current price or 24-hour statistics.

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 prerequisite guidance: 'First call exchange info or symbol listing to discover valid trading pairs, then query market data.' This establishes the workflow context, though it does not explicitly name alternative tools for different price types.

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

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

With no annotations provided, the description carries significant burden by disclosing IP rate limiting weights (5-250 based on limit ranges) and the exact return JSON structure. This reveals critical operational costs and response format not available in structured fields. Missing only auth requirements and caching 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 content is information-dense and front-loaded with the resource name, but the formatting mixes markdown tables with inline JSON return structures in a way that reduces readability for parsing. While no sentences are wasted, the structural formatting is suboptimal.

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

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

Given the absence of annotations and output schema, the description successfully compensates by providing rate limit costs, return type documentation, and prerequisite workflow. For a public market data endpoint, this covers the essential operational context needed 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?

Input schema has 100% coverage with descriptions for both 'symbol' and 'limit'. The description adds the rate limit weight table which contextualizes the cost implications of different limit values, but does not add semantic detail about the symbol parameter beyond the schema's 'Trading symbol' description. Baseline 3 is appropriate given schema completeness.

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

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

The description identifies the resource as 'Order Book' and documents the return structure (bids/asks arrays), but uses terse phrasing rather than a clear verb statement. It does not explicitly distinguish this from sibling market data tools like get_api_v3_ticker or get_api_v3_trades, leaving ambiguity about when to select this specific endpoint.

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

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

Provides a clear prerequisite workflow ('First call exchange info or symbol listing to discover valid trading pairs, then query market data'), which establishes necessary sequencing. However, it lacks explicit 'when-not-to-use' guidance or comparisons to alternative market data endpoints that might be more appropriate for different use cases.

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

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

No annotations are provided, so the description carries the full burden. It discloses error behavior (throws error for invalid symbols) and default parameter values, but omits rate limiting, caching behavior, or safety characteristics that would be essential for a read-only discovery endpoint.

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 contains useful information but suffers from poor structure—bullet points are mixed into a paragraph format with dashes, and the text ends abruptly mid-sentence ('means you may place an order if you'). The front-loading is adequate with the [DISCOVERY] tag, but the truncation significantly hurts readability.

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

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

Given that no output schema exists and the description is cut off mid-explanation of response interpretation ('Examples of Symbol Permissions Interpretation'), the definition is incomplete. It attempts to document return value semantics but fails to finish the explanation, leaving agents without full context for the response structure.

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 100% schema description coverage, the baseline is adequate, but the description adds significant value by specifying default permission values (["SPOT","MARGIN","LEVERAGED"]), format examples for single vs multiple values, and the constraint that symbols are optional. It also explains the semantics of the permissions parameter beyond the schema.

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

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

The description clearly states it retrieves 'Current exchange trading rules and symbol information' with a [DISCOVERY] tag, providing a specific verb and resource. However, it doesn't explicitly differentiate from sibling market data tools like get_api_v3_ticker or get_api_v3_depth, though the 'trading rules' focus provides implicit distinction.

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

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

The description mentions specific constraints (throws error if symbol doesn't exist, all parameters are optional) and default permission values, which helps with usage. However, it lacks explicit guidance on when to use this versus other market data endpoints or prerequisites for 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?

Without annotations, the description carries the full burden. It adds 'Weight(IP): 10' for rate limiting context and specifies 'older' to define data scope, but omits safety profile (read-only confirmation), pagination cursor behavior details, and error handling expectations for this historical data endpoint.

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 in two efficient sections: the first sentence front-loads purpose and weight, while the second provides prerequisite context. No sentences are wasted on tautology or redundant schema information.

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

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

Given the simple flat schema (3 parameters) and lack of output schema or annotations, the description adequately covers prerequisites and rate limits. However, it lacks safety disclosures and detailed behavioral constraints (e.g., how 'old' the data can be) that would fully contextualize the tool.

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

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

Schema description coverage is 100%, documenting symbol, limit defaults/maximums, and fromId behavior. The description adds minimal parameter semantics beyond the prerequisite's implicit reference to valid symbols, meeting the baseline for well-schematized tools.

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

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

The description states 'Get older market trades' with the prefix 'Old Trade Lookup', providing a specific verb and resource. It clearly distinguishes this tool from the sibling get_api_v3_trades (recent trades) and get_api_v3_my_trades (user-specific trades) by specifying 'older' market data.

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

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

The PREREQUISITE section explicitly states 'First call exchange info or symbol listing to discover valid trading pairs,' providing clear workflow sequencing. However, it does not explicitly name alternative tools (e.g., 'use get_api_v3_trades for recent data instead') or specify when-not-to-use scenarios.

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

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

No annotations are provided, so the description carries the full burden. It discloses rate limiting ('Weight(IP): 2') and default temporal behavior, but lacks safety classification (read-only vs. write) and does not describe return format, pagination, or error conditions.

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 structured with two distinct sections (functionality/description and prerequisites). The em-dash formatting is slightly unconventional but does not impede clarity. Every sentence provides actionable information.

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

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

Given 6 parameters with full schema coverage, the description adequately covers inputs and prerequisites. However, with no output schema provided, the description should ideally describe the kline data structure (OHLCV fields). Missing explicit safety/authorization context.

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 100% schema description coverage, the baseline is 3. The description adds value by explaining the conditional logic for startTime/endTime ('If not sent, the most recent klines are returned') and providing the IP weight context, which aids in parameter usage planning.

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

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

The description clearly states it retrieves 'Kline/candlestick bars for a symbol' and explains unique identification by open time. However, it does not distinguish from the sibling tool 'get_api_v3_ui_klines', leaving ambiguity about which kline endpoint to use.

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 PREREQUISITE section explicitly states to 'First call exchange info or symbol listing to discover valid trading pairs,' providing clear workflow guidance. It also explains default behavior when time parameters are omitted. Missing explicit mention of alternatives or when NOT to use this vs. 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?

No annotations provided, so description carries full burden. It discloses 'Weight: 20' (rate limiting), 'USER_DATA' (authentication scope), and explains result ordering logic (oldest to newest, filtering behavior). However, missing error behaviors, pagination cursor details, or response structure description.

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?

Information is front-loaded and dense, but the text appears truncated ('Note: The time between star'). The parameter combinations section is somewhat wall-of-text formatted but parseable. Contains minimal 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?

With 9 parameters and no output schema, the description adequately covers query construction and prerequisites. However, it lacks description of return values or the truncation leaves a behavioral note incomplete, slightly undermining completeness for a complex filtered query tool.

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

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

Schema coverage is 100%, establishing baseline 3. The description adds significant value by detailing parameter interaction semantics (e.g., 'symbol + endTime newest allocations until endTime'), explaining how combinations affect result sets beyond individual parameter definitions.

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

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

The description clearly states it 'Retrieves allocations resulting from SOR order placement' — specific verb (retrieves), specific resource (SOR allocations), and distinguishes from siblings like get_api_v3_my_trades or get_api_v3_order by specifying 'allocations' from 'SOR' 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 PREREQUISITE to first call exchange info for valid symbols. Lists specific supported parameter combinations (e.g., 'symbol + startTime' vs 'symbol + orderId') that guide the agent on valid query construction. Lacks explicit 'when not to use' guidance.

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

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

With no annotations provided, the description carries the burden of disclosing behavioral traits. It successfully documents rate limiting costs, default pagination values, and read-only nature (implied by 'Query'). Minor gap: does not explicitly confirm idempotency or elaborate on error responses beyond invalid symbol weight.

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?

Information-dense and front-loaded with purpose. The parameter combinations and prerequisites are structured logically. Minor deduction for formatting density (asterisk lists without markdown spacing) and the Weight section being somewhat compressed, though all content is relevant.

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

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

Given no output schema exists, the description explains the conceptual return (list of expired orders) and references external STP documentation for domain context. Covers prerequisites and rate limits thoroughly. Minor gap: does not describe the structure/fields of the returned order objects.

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

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

Input schema has 100% description coverage establishing a baseline of 3. The description adds significant value by explaining valid parameter combinations and dependencies (e.g., that limit defaults to 500 only when using fromPreventedMatchId with orderId), which is semantic information not present in individual parameter descriptions.

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

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

Description clearly states it 'Displays the list of orders that were expired because of STP' and defines the resource (Prevented Matches/Self Trade Prevention). It effectively distinguishes from sibling tools like get_api_v3_my_trades or get_api_v3_all_orders by specifying the STP-specific 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?

Explicitly lists valid parameter combinations (symbol + preventedMatchId, symbol + orderId, etc.), states default behaviors (limit defaults to 500), and includes a PREREQUISITE section advising to first call exchange info. Also documents rate limiting weights (Weight(IP): 2 vs 20) for different query patterns.

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

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

With no annotations provided, the description carries the full burden. It successfully discloses rate limiting ('Weight(IP): 20') and pagination behavior (fromId logic), but fails to explicitly state this is a read-only operation, describe error scenarios, or mention authentication requirements beyond the signature parameter in the schema.

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

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

The description is information-dense but poorly structured. The parameter combinations run together without clear separators ('symbol symbol + orderId symbol + startTime'), making them hard to read. The prerequisite section is clearly demarcated, but the main description mixes behavioral details, constraints, and rate limits without clear paragraph breaks.

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 9-parameter tool with no output schema and no annotations, the description covers essential operational constraints (rate limits, time windows, parameter dependencies) and prerequisites. It appropriately focuses on input constraints given the absence of output schema, though it could briefly mention the return data structure (list of trades).

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 100% schema coverage, the baseline is 3. The description adds significant value by documenting valid parameter combinations (e.g., 'symbol + orderId', 'symbol + startTime + endTime') and temporal constraints (24-hour max window) that are not evident from the schema alone, though the formatting of these combinations is difficult to parse.

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

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

The description clearly states it retrieves 'trades for a specific account and symbol' with specific verb and resource, and the 'USER_DATA' label distinguishes it from public trade endpoints like get_api_v3_trades. However, it ambiguously mentions 'orders' ('most recent orders are returned') when this tool specifically retrieves trades/fills, potentially confusing it with sibling order query tools like get_api_v3_all_orders.

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

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

Provides explicit prerequisite ('First call exchange info or symbol listing') and critical constraints including the 24-hour time window limit, valid parameter combinations, and rate limit weight (20). Deducting one point because it doesn't explicitly distinguish when to use this versus margin trades endpoint (get_sapi_v1_margin_my_trades) or clarify the difference between querying trades versus orders.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable rate-limiting context ('Weight(IP): 6'), but fails to disclose safety characteristics (read-only vs. destructive), return value structure, or pagination behavior that would be essential for safe invocation.

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

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

The description is extremely concise (single sentence/fragment) and front-loaded with the action. The '[DISCOVERY]' prefix appears to be metadata noise, but the core content efficiently conveys the endpoint purpose and rate limit without redundant text.

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

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

Given the absence of annotations and output schema, and the presence of numerous confusingly similar siblings (get_api_v3_open_orders, get_api_v3_order_list, etc.), the description is incomplete. It lacks explanation of return values, pagination, and crucially, how 'Open OCO' differs from other open order types.

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

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

The input schema has 100% description coverage (signature, timestamp, recvWindow are all documented). The description adds no additional parameter semantics, but the rubric baseline of 3 applies for high schema coverage scenarios where the schema itself carries the descriptive load.

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

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

The description states the specific action 'Query' and resource 'Open OCO', and identifies the endpoint as 'USER_DATA'. However, it does not distinguish this tool from siblings like 'get_api_v3_open_orders' or 'get_api_v3_order_list', nor does it explain what 'OCO' (One-Cancels-Other) means for users unfamiliar with trading terminology.

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 '(USER_DATA)' tag implicitly signals that authentication is required, but the description provides no explicit guidance on when to use this tool versus the many sibling order-querying tools (e.g., get_api_v3_all_order_list, get_api_v3_open_orders). No prerequisites or alternative selection criteria are provided.

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

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

With no annotations provided, the description carries the full burden. It discloses API weight costs (6 vs 80) and implies authentication via 'USER_DATA' and the required signature/timestamp parameters. However, it lacks disclosure of pagination behavior, return data structure, caching, or error conditions that would help predict runtime behavior.

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

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

The description is efficiently structured with zero waste: sentence 1 identifies the operation and data type, sentence 2 provides the critical usage warning, and sentence 3 details the cost structure. Information is front-loaded and every sentence earns its place.

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

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

Given the tool has 4 parameters with 100% schema coverage but no output schema and no annotations, the description adequately covers the primary usage concern (cost/weight implications). However, it lacks documentation of what the tool returns (array of orders, pagination, etc.), which would be helpful since no output schema exists to describe the response format.

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

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

Schema description coverage is 100%, providing descriptions for all 4 parameters including examples for symbol and recvWindow. The description text adds implicit confirmation that 'symbol' is optional ('when the symbol parameter is omitted'), but otherwise doesn't add syntax details or usage examples beyond what the schema already provides. Baseline 3 is appropriate given the schema completeness.

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 'Get all open orders on a symbol' with the specific verb 'Get' and resource 'open orders'. It distinguishes from siblings like get_api_v3_order (specific order lookup) and get_api_v3_all_orders (historical orders) by emphasizing 'Current' and 'Open' orders. The USER_DATA tag further clarifies the access 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?

Provides explicit cost guidance ('Weight(IP): 6 for a single symbol; 80 when symbol is omitted') and warns 'Careful when accessing this with no symbol'. This effectively guides when to use the symbol parameter versus omitting it, though it doesn't explicitly name alternative tools for different query 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?

With no annotations provided, the description carries the full burden and succeeds: it discloses 'Weight(IP): 4' for rate limiting, warns about historical data availability ('cummulativeQuoteQty will be < 0'), indicates authentication scope via '(USER_DATA)', and sketches return 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?

Information-dense with zero filler, though slightly run-on. The structure logically flows from purpose → constraints → rate limit → returns → prerequisites. Every sentence earns its place, though bullet formatting would improve scannability.

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?

Comprehensive for a query tool: covers authentication context, rate limiting, return structure hint, and prerequisite workflow. Lacks explicit error scenario documentation, but this is sufficient given the schema completeness and tool complexity.

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?

While the schema has 100% coverage (baseline 3), the description adds crucial semantic constraints: the XOR requirement between orderId and origClientOrderId ('Either...must be sent'), which JSON schema cannot express. It also contextualizes signature/timestamp within USER_DATA authentication.

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 specific verbs ('Query', 'Check') and the resource ('Order'), clearly indicating this retrieves a single order's status. The '(USER_DATA)' tag immediately signals authentication requirements, distinguishing it from public market data tools like get_api_v3_ticker.

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

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

Provides explicit workflow guidance via 'PREREQUISITE: First call exchange info or symbol listing...' and critical parameter logic 'Either `orderId` or `origClientOrderId` must be sent'. Deducting one point as it doesn't explicitly name sibling alternatives (e.g., 'use get_api_v3_all_orders to list multiple orders').

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

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

With no annotations provided, the description carries the full burden. It successfully discloses the rate limit 'Weight(IP): 4' and previews the return structure with field names and types. However, it lacks details on error behavior (e.g., what happens if the OCO doesn't exist), authentication specifics, or whether the parameters are mutually exclusive filters.

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 dense and information-heavy but cluttered with metadata tags like '[DISCOVERY]' and '(USER_DATA)' that reduce readability. While it efficiently packs rate limits, return types, and purpose into one sentence, the structure could be improved by front-loading the core action and separating metadata.

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 tool with 5 simple parameters and no nested objects, the description is minimally adequate. It covers the basic retrieval purpose, rate limiting, and return structure, but leaves gaps in error handling, parameter interaction logic, and sibling differentiation that would be necessary for robust agent operation.

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

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

With 100% schema description coverage, the baseline is appropriately 3. The description adds minimal semantic value beyond the schema, merely noting that parameters are 'optional' (which aligns with only timestamp/signature being required). It does not clarify the relationship between orderListId and origClientOrderId or provide usage examples.

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

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

The description clearly states the tool 'Retrieves a specific OCO' with a specific verb and resource (OCO order list). However, it does not differentiate from similar sibling tools like get_api_v3_all_order_list or get_api_v3_open_order_list, which also query OCO orders but with different scope (all vs. open vs. specific). The '[DISCOVERY]' prefix appears to be metadata noise that doesn't aid comprehension.

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

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

The description provides no guidance on when to use this tool versus alternatives like get_api_v3_all_order_list or get_api_v3_open_order_list. It does not indicate whether to use orderListId or origClientOrderId (or both), nor does it mention prerequisites like authentication requirements beyond the implicit 'USER_DATA' tag.

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

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

With no annotations provided, the description carries the full burden. It provides valuable operational context by specifying 'Weight(IP): 1', indicating rate limit costs. However, it omits other behavioral traits such as authentication requirements, idempotency, or the structure of the ping response.

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 appropriately compact and front-loaded: 'Test Connectivity' establishes purpose immediately, followed by the rate limit detail. Every word earns its place with no redundant filler.

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

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

Given the tool's simplicity (no parameters, no output schema), the description is reasonably complete by including the rate limit weight—a critical operational detail for API health checks. It could be improved by mentioning the expected return payload or authentication behavior, but it suffices for a basic ping endpoint.

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 contains zero parameters. Per the scoring rules, zero-parameter tools receive a baseline score of 4, as there are no parameter semantics to describe beyond what the empty schema already conveys.

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 'Test[s] connectivity to the Rest API' using a specific verb and resource. It effectively distinguishes this simple health-check endpoint from the numerous complex trading and account management siblings (e.g., order operations, margin endpoints).

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

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

The description implies usage through the phrase 'Test Connectivity,' indicating it should be used to verify API reachability. However, it fails to differentiate this tool from similar status-checking siblings like 'get_api_v3_time' or 'get_sapi_v1_system_status', leaving ambiguity about which diagnostic tool to use when.

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

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

With no annotations provided, the description carries the full burden. It discloses the 'Weight(IP): 40' cost metric and identifies this as a 'TRADE' endpoint (implying authentication required), but lacks explicit safety declarations (read-only status), error behavior, or return value structure.

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

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

The description is extremely concise with two information-dense sentences. The purpose is front-loaded ('Query Current Order Count Usage'), followed by scope and technical metadata. No redundant or wasteful text 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?

Given the absence of annotations and output schema, the description adequately covers the core concept (querying order count usage) but omits details about the response structure, pagination, or specific authentication requirements. Sufficient for a simple query tool but leaves gaps for implementation.

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

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

Schema description coverage is 100% (all 3 parameters have descriptions). The description text itself does not elaborate on parameter semantics, syntax, or provide examples beyond what the schema provides. Baseline 3 is appropriate given the schema does the heavy lifting.

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

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

The description uses specific verbs ('Query', 'Displays') and identifies the resource ('Order Count Usage') with clear scope ('TRADE', 'all intervals'). However, it does not explicitly distinguish from the sibling margin rate limit tool (get_sapi_v1_margin_rate_limit_order) by mentioning 'spot' or comparing functionality.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites like authentication requirements (implied only by 'TRADE' and 'signature' parameter). No comparison to the margin equivalent or other rate limit endpoints is provided.

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

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

With no annotations provided, the description carries the full burden and successfully discloses critical behavioral traits: the window calculation quirk (effective window up to 1 minute wider than requested due to minute-alignment), openTime/closeTime behavior, and rate limiting details (Weight(IP): 4 per symbol, cap at 20). It lacks explicit mention that this is a safe read-only 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 leads with the purpose but then becomes somewhat verbose with the timestamp example. The rate limiting information is valuable but buried at the end. The '[DISCOVERY]' prefix appears to be metadata rather than descriptive content. Structure could be improved by separating behavioral constraints from usage guidance.

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

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

Given the absence of an output schema, the description should ideally document return values, which it does not. However, it adequately covers the complex window calculation behavior given the parameter set. For a 4-parameter read tool with no annotations, the description covers operational behavior but leaves output structure undocumented.

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

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

Input schema has 100% description coverage, establishing a baseline of 3. The description provides an example timestamp calculation that implicitly clarifies windowSize behavior, but does not add significant semantic detail beyond what the schema already specifies for the type, symbol, or symbols parameters.

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 identifies the tool's purpose as retrieving 'Rolling window price change statistics' with specific verb and resource identification. However, it fails to explicitly differentiate from sibling ticker tools (get_api_v3_ticker_24hr, get_api_v3_ticker_price, etc.), leaving the agent to infer from the windowSize parameter that this supports custom time windows.

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

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

No guidance is provided on when to use this tool versus alternatives like get_api_v3_ticker_24hr or get_api_v3_ticker_trading_day. There are no stated prerequisites, exclusions, or recommended use cases beyond the technical description of window behavior.

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

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

With no annotations provided, the description carries the full burden. It successfully discloses critical behavioral traits: the high IP weight cost (80) when omitting symbol versus single symbol queries (2), and the return format change (array of all symbols vs single object). It does not, however, disclose authentication requirements or detailed rate limiting beyond the weight values.

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 suffers from immediate redundancy ('24hr Ticker Price Change Statistics — 24 hour rolling window price change statistics'). While the weight information is valuable, the formatting with inline dashes and backticks is somewhat messy. The content is front-loaded but could be more efficiently structured without the tautological opening.

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 lack of an output schema, the description should ideally describe the return structure (e.g., fields like priceChange, weightedAvgPrice, volume). It mentions the array return format when no symbol is provided, but omits details about the ticker data structure. The critical cost/weight warning is present, but the description remains incomplete regarding response semantics.

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

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

The input schema has 100% description coverage, establishing a baseline of 3. The description adds value by explaining the weight cost implications of the symbol parameter, but it fails to clarify the relationship or distinction between the singular 'symbol' and plural 'symbols' parameters, or provide additional context for the 'type' parameter beyond the schema's basic enum 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 clearly identifies the resource as '24hr Ticker Price Change Statistics' and specifies the '24 hour rolling window' scope. While it defines the tool's specific function adequately, it does not explicitly differentiate from sibling ticker endpoints like get_api_v3_ticker or get_api_v3_ticker_price, though the '24hr' and 'price change' qualifiers provide implicit differentiation.

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

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

The description provides explicit usage warnings ('Careful when accessing this with no symbol') and details the cost implications (Weight(IP): 2 vs 80) when omitting the symbol parameter. However, it lacks guidance on when to use this versus alternative ticker endpoints or whether authentication is required.

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

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

With no annotations provided, the description carries the full burden. It successfully discloses rate limiting weights and return format variations (array vs single object), but does not address other behavioral traits like caching, update frequency, or whether the data is real-time versus delayed.

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 structured with the purpose front-loaded, followed by parameter behavior and rate limits. The '[DISCOVERY]' prefix appears to be metadata noise, but the remaining content is dense and actionable with minimal 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?

Without an output schema, the description partially compensates by explaining what data is returned (best price/qty) and the format variation (array vs object). However, it lacks details on the specific fields returned (bid price, bid quantity, ask price, ask quantity) which would be necessary for full completeness given the absence of structured output documentation.

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

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

Schema description coverage is 100%, establishing a baseline of 3. The description adds context about omitting the 'symbol' parameter, but fails to clarify the distinction between the 'symbol' and 'symbols' parameters or when to use the plural form for specific multiple symbol queries.

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 identifies this as an 'Order Book Ticker' tool that retrieves 'Best price/qty on the order book', distinguishing it from sibling ticker endpoints (e.g., get_api_v3_ticker_24hr, get_api_v3_ticker_price) by specifying it returns order book level data rather than statistical or simple price data.

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

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

Provides explicit operational guidance including IP weight costs ('2' for single symbol vs '4' for all symbols) and explains the behavioral difference between providing a symbol (single object) versus omitting it (array of all symbols). However, it lacks explicit comparison to similar ticker tools to help agents choose between them.

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

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

With no annotations provided, the description carries the full burden. It discloses rate-limiting weights (IP: 2 for single, 4 for all) and return format differences (array when no symbol), but omits authentication requirements, caching behavior, or whether the data is real-time vs cached.

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 appropriately sized with three distinct segments: the title/purpose, the optional parameter behavior, and the rate limiting weights. Information is front-loaded with the core purpose, and every sentence provides actionable information with no 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?

For a simple read-only endpoint with 2 parameters and 100% schema coverage, the description is reasonably complete. It covers the primary use case (single vs all symbols) and critical rate-limiting constraints. Without an output schema, it appropriately focuses on input behavior.

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

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

The schema has 100% description coverage, establishing a baseline of 3. The description adds context about omitting the 'symbol' parameter but fails to clarify the relationship between the 'symbol' and 'symbols' parameters (mutually exclusive vs combinable) or when to use the JSON array format.

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

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

The description clearly states it retrieves the 'Latest price for a symbol or symbols' with a specific verb and resource. While it distinguishes implicitly from siblings like get_api_v3_ticker_24hr by focusing on 'latest price' rather than statistics, it doesn't explicitly contrast with related ticker endpoints.

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 implicit usage guidance by explaining that omitting the symbol returns all prices in an array, and details the IP weight costs (2 vs 4) to inform rate-limiting decisions. However, it lacks explicit when-to-use guidance comparing it to alternatives like get_api_v3_ticker or get_api_v3_avg_price.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully documents the weight-based rate limiting (4 per symbol, cap at 200) and timezone handling formats, but fails to describe the response structure, authentication requirements, or what specific statistics are returned (OHLC, percentage change, volume, etc.).

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 information is front-loaded with the purpose statement first, followed by technical notes. However, the formatting using dashes and backticks for the notes section is somewhat fragmented and inconsistent, detracting slightly from readability while maintaining adequate information density.

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

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

Given the absence of an output schema and annotations, the description provides partial compensation through rate limit and timezone details. However, it omits description of return values or data structure, leaving agents uncertain about what specific 'price change statistics' fields will be returned (e.g., open, high, low, close, volume).

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 100% schema coverage, the description adds significant value by detailing the timezone format syntax (e.g., '-1:00', '05:45', '0') beyond the schema's simple 'Default: 0' note. It also explains how the 'symbols' parameter affects rate limiting weight, providing crucial usage context not present in the schema definitions.

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 identifies the tool retrieves 'Price change statistics for a trading day,' specifying both the action (statistics retrieval) and the temporal scope (trading day vs. rolling 24h). The em-dash format effectively separates the title from the purpose, though it doesn't explicitly contrast with sibling ticker endpoints like get_api_v3_ticker_24hr.

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

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

The description provides no guidance on when to select this tool over the numerous sibling ticker endpoints (get_api_v3_ticker_24hr, get_api_v3_ticker_price, etc.). While it includes operational rate-limiting details, it lacks conditional logic or use-case scenarios that would help an agent choose this specific ticker variant.

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

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

With no annotations provided, the description carries the full burden. It successfully discloses the rate-limiting weight ('Weight(IP): 1') and documents the return structure ('{ serverTime: number }') despite the absence of a formal output schema. It does not, however, explicitly state the read-only/safe nature of the 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 compact and front-loaded with the primary function ('Check Server Time'). Every segment earns its place: the em-dash separates concerns, the weight disclosure informs rate-limit planning, and the return format compensates for missing schema documentation. No wasted words.

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

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

For a simple utility endpoint with zero parameters and no annotations, the description is sufficiently complete. It documents the return value (which the schema omits) and rate-limit costs. A minor gap is the lack of explicit read-only safety classification, though this is inferable from the verbs used.

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

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

The tool has zero parameters, establishing a baseline score of 4 per the scoring rules. The description appropriately does not fabricate parameter details.

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

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

The description clearly states the dual purpose: testing connectivity and retrieving server time using specific verbs ('Check', 'Test', 'get'). While it implies differentiation from the sibling 'get_api_v3_ping' by mentioning time retrieval (not just connectivity), it does not explicitly distinguish between these two similar utilities.

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

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

The description implies usage scenarios (testing connectivity or needing server time) but provides no explicit guidance on when to prefer this over 'get_api_v3_ping' or other health-check alternatives. It lacks 'when-not-to-use' constraints or prerequisites.

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

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

With no annotations provided, the description carries the full burden. It discloses rate limiting ('Weight(IP): 10'), which is valuable behavioral context. However, it omits other critical behavioral details such as data freshness/latency, whether the data is public or requires authentication, or pagination behavior beyond the limit parameter.

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 structured with a clear header ('Recent Trades List'), concise action statement, rate limit note, and a clearly separated prerequisite section. Every sentence provides 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?

Given the low complexity (2 simple parameters, no nested objects, no output schema), the description is reasonably complete. The prerequisite fills a critical gap regarding valid symbol discovery. It could be improved by clarifying the distinction between this and sibling trade endpoints (historical, aggregated, personal) given the rich sibling ecosystem.

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

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

Schema description coverage is 100%, establishing a baseline of 3. The description adds indirect semantic value for the 'symbol' parameter via the prerequisite note about discovering valid trading pairs first, but does not elaborate on parameter formats, validation rules, or the temporal semantics of 'recent' beyond the schema's existing descriptions.

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

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

The description clearly states it retrieves 'recent trades' with a specific verb (Get) and resource (trades). The term 'recent' helps distinguish it from the sibling 'get_api_v3_historical_trades', though it does not explicitly differentiate from 'get_api_v3_agg_trades' or clarify that these are public market trades versus the private 'my_trades' sibling.

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

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

Provides explicit prerequisite guidance ('First call exchange info or symbol listing to discover valid trading pairs'), establishing a required sequence for successful invocation. However, it lacks explicit 'when-not-to-use' guidance or direct comparisons to alternative trade endpoints (e.g., historical vs. recent).

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

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

With no annotations provided, the description carries the full burden. It successfully discloses the rate limit ('Weight(IP): 2') and notes the response similarity to klines, but fails to explain what specific modifications are made to the data to optimize it for UI presentation (e.g., rounding, formatting changes) or mention idempotency/cache 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 reasonably compact at four sentences, but the structure is fragmented with the 'UIKlines —' header being redundant with the tool name, and 'PREREQUISITE:' in all caps creating visual noise. The weight information feels isolated on its own 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?

Given the absence of an output schema and annotations, the description provides the minimum viable context: it references the similar response structure of 'klines' and includes the prerequisite call sequence. However, it should ideally describe the actual return format or fields since no output schema exists to document them.

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 100% description coverage, establishing a baseline of 3. The description adds value by noting parameters are the 'same' as the klines endpoint, which helps agents transfer knowledge from the sibling tool. However, it does not elaborate on parameter semantics beyond what the schema already provides (e.g., valid interval values).

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 returns 'modified kline data, optimized for presentation of candlestick charts,' distinguishing it from the sibling tool 'get_api_v3_klines' by specifying the UI optimization use case. However, the opening 'UIKlines —' partially restates the tool name, slightly diluting the specificity.

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

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

The description provides a clear prerequisite ('First call exchange info or symbol listing...') which helps with sequencing. However, it lacks explicit guidance on when to choose this over the standard 'klines' endpoint beyond the vague 'optimized for presentation,' missing the opportunity to clarify the decision criteria.

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

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

Without annotations, the description carries the burden of behavioral disclosure. It successfully includes rate limit information ('Weight(IP): 1') and hints at the return structure with specific fields (ipRestrict, enableInternalTransfer), but lacks information on error cases, caching behavior, or authentication requirements.

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

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

The description is extremely compact and front-loaded with the action verb. It efficiently packs the permission type, rate limit weight, and return structure into a single sentence. The dense notation (e.g., 'Weight(IP): 1') is efficient for technical users though slightly cryptic.

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 lack of an output schema, the description partially compensates by listing example return fields (ipRestrict, createTime, enableInternalTransfer). However, the ellipsis suggests incomplete return documentation, and with no annotations provided, the description could better explain the security implications of the API restrictions being queried.

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 100% schema description coverage, the baseline score applies. The description does not add semantic meaning beyond what the schema already provides for signature, timestamp, and recvWindow parameters, but the schema is sufficiently documented that additional description is not necessary.

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

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

The description clearly states the action 'Get API Key Permission' and identifies the specific resource being accessed. It distinguishes from sibling tools like 'get_sapi_v1_sub_account_sub_account_api_ip_restriction' by omitting sub-account references, though it could explicitly specify 'current account' to make the distinction clearer.

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

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

No guidance provided on when to use this tool versus alternatives, nor any prerequisites mentioned. The 'USER_DATA' tag implies authentication requirements but this is not explained for users unfamiliar with Binance API permission types.

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

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

With no annotations provided, the description carries the full burden and succeeds reasonably well. It discloses the rate limit weight ('Weight(IP): 1'), indicates authentication requirements via '(USER_DATA)' tag, and provides a complete JSON return structure showing fields like isLocked, plannedRecoverTime, and triggerCondition (GCR/IFER/UFR) that reveal the tool checks trading restrictions and risk metrics.

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 information-dense and front-loaded with the essential verb and resource. However, the inline JSON return structure, while valuable due to the lack of output schema, creates a dense single-line format that hinders readability. Every element serves a purpose, but structure could be improved.

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

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

Despite having no output schema and no annotations, the description compensates effectively by embedding the complete return structure inline, including nested objects (triggerCondition, indicators). It adequately documents what the caller receives, making it functionally complete for a read-only status check tool with three parameters.

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

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

Schema description coverage is 100%, documenting timestamp, signature, and recvWindow adequately. The description adds no parameter-specific context, but since the schema is fully self-documenting, it meets the baseline expectation without penalty.

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

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

The description uses the specific verb 'Fetch' with the resource 'account API trading status', clearly indicating it retrieves trading lock status and risk indicators. It distinguishes from siblings like get_api_v3_account (general balances) and get_sapi_v1_account_status (account status) by focusing specifically on API trading permissions and risk metrics (isLocked, triggerCondition fields).

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

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

The description provides no guidance on when to use this tool versus similar account information tools like get_sapi_v1_account_status or get_api_v3_account. No prerequisites (beyond implicit USER_DATA auth), exclusions, or alternatives are mentioned.

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

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

With no annotations provided, the description carries the full burden and succeeds in disclosing the rate limit weight (Weight(IP): 1) and the exact return structure since no output schema exists. The 'USER_DATA' classification indicates authentication requirements. It lacks error behavior or caching details, but covers the critical behavioral traits for a rate-limited API.

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

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

The description is a single, dense sentence with zero waste. It front-loads the category (USER_DATA), states the action, provides the rate limit, and documents the return value—every clause earns its place.

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

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

For a simple 3-parameter fetch tool with 100% schema coverage but no output schema, the description is reasonably complete. It compensates for the missing output schema by documenting return values and includes the rate limit weight. It could be improved with error code documentation or cache behavior notes.

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 100% schema description coverage, the baseline is appropriately 3. The description does not add semantic details about the parameters beyond what the schema already provides (e.g., it doesn't explain the relationship between signature and timestamp or the purpose of recvWindow).

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

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

The description clearly states it fetches account info and specifies exact return fields (vipLevel, isMarginEnabled, isFutureEnabled) that distinguish it from sibling account endpoints like get_api_v3_account. The 'USER_DATA' tag clarifies the endpoint category. However, it doesn't explicitly differentiate when to use this versus the main account endpoint.

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

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

The description provides no guidance on when to use this tool versus the many sibling account tools (e.g., get_api_v3_account, get_sapi_v1_account_status). There are no prerequisites mentioned beyond the implicit authentication required by the signature parameter.

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

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

With no annotations provided, the description carries the full burden. It discloses the rate limit 'Weight(IP): 2400' and default temporal behavior, which is valuable. However, it omits crucial behavioral details like what the snapshot records contain, response format, or pagination 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 suffers from poor formatting—mixing em-dashes with bullet dashes ('— -') and lacking clear sentence structure. It contains a typo ('startTimeand'). While information-dense, the presentation is messy and harder to parse than necessary.

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 lack of output schema and the tool's complexity (7 parameters including authentication), the description is incomplete. It fails to describe the return values, response structure, or what specific account data is returned in the snapshot, leaving significant gaps for an agent trying to interpret results.

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

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

The input schema has 100% description coverage, establishing a baseline of 3. The description adds value by explaining the default behavior when startTime/endTime are omitted, though it contains a typo ('startTimeand'). It does not add significant semantic context for other parameters like 'type' or 'signature' 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 identifies the tool as retrieving 'Daily Account Snapshot' data, which indicates the general resource. However, it fails to specify what data the snapshot contains (balances, positions, transactions) or distinguish this from sibling tools like get_api_v3_account (current state) versus this historical snapshot endpoint.

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 operational constraints—'query time period must be less than 30 days,' 'last one month only,' and default behavior (last 7 days if no time range). However, it lacks guidance on when to prefer this over alternatives like get_api_v3_account for real-time data.

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

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

No annotations provided, so description carries full burden. Adds valuable rate limit info ('Weight(IP): 1') and return type ('Returns: { data: string }'), but lacks explicit read-only declaration or error behavior details.

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

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

Extremely efficient four-part structure labeling the endpoint, stating purpose, specifying weight, and defining return type. No wasted words.

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

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

Adequate for a simple 3-parameter endpoint with full schema coverage. Compensates for missing output schema by documenting return type, but lacks domain context distinguishing 'account status' from other account attributes.

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 has 100% description coverage (timestamp, signature, recvWindow all documented), establishing baseline 3. Description adds no additional parameter context, which is acceptable given schema completeness.

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 specific verb 'Fetch' and resource 'account status', but fails to differentiate from similar sibling tools like get_sapi_v1_account_info or get_api_v3_account.

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 no guidance on when to use this tool versus alternatives, nor any prerequisites or conditions for use.

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

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

With no annotations provided, the description carries significant weight. It discloses authentication requirements (Futures Trading Permission), rate limiting ('Weight(IP): 1'), and importantly provides the return structure inline ('Returns: { total: number, orders: ... }') since no output schema exists. It does not mention pagination limits or error behaviors.

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?

Every element carries information (permission, URL, weight, return structure), but the formatting is cramped and inconsistent—using an em-dash followed by hyphens for bullets and inline JSON without code formatting. This reduces scannability despite the high information density.

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

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

Given the absence of annotations and output schema, the description adequately compensates by specifying the return payload structure, permission gates, and rate limits. It covers the essential behavioral contract for a historical data query tool, though it could clarify pagination behavior.

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

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

The input schema has 100% description coverage (e.g., 'UTC timestamp in ms', 'MIN 1, MAX 100'), so the description is not required to compensate. The description does not add additional parameter semantics, syntax guidance, or cross-parameter relationships (e.g., startTime/endTime pairing) beyond what the schema provides.

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

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

The description clearly identifies the action ('Query') and resource ('Historical Algo Orders') with scope ('USER_DATA'). The term 'Historical' distinguishes it from the sibling 'get_sapi_v1_algo_futures_open_orders', though it doesn't explicitly mention 'futures' in the descriptive text (relying on the permission requirement and tool name instead).

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

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

The description provides a critical prerequisite: 'You need to enable Futures Trading Permission for the api key'. However, it lacks explicit guidance on when to use this versus the 'open_orders' variant or the spot market equivalent, forcing the agent to infer from the 'Historical' keyword.

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

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

With no annotations provided, the description carries the full burden. It discloses 'Weight(IP): 1' (rate limiting) and provides the return structure inline ('Returns: { total: number, orders:... }'), which compensates for the missing output schema. However, it lacks explicit safety declarations (e.g., confirming read-only status) or error handling details.

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 information-dense but poorly structured, mashing bullet points together with dashes ('— - You need...'). While every fragment adds value (auth, rate limit, return type), the lack of clear formatting reduces readability.

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

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

Given the lack of output schema and annotations, the description partially compensates by providing the JSON return structure and auth requirements. However, it omits safety hints, pagination details, and field descriptions for the return object, leaving gaps for a USER_DATA endpoint.

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

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

The input schema has 100% description coverage (signature, timestamp, recvWindow are all documented). Since the schema fully documents the parameters, the description baseline is appropriately 3, though the description itself adds no parameter-specific guidance.

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 'Query Current Algo Open Orders (USER_DATA)', providing a specific verb and resource. It distinguishes from siblings like get_sapi_v1_algo_futures_historical_orders (current vs. historical) and get_sapi_v1_algo_spot_open_orders (futures vs. spot) through the name and 'Current' modifier, though it could explicitly mention these distinctions.

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

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

It states the prerequisite 'You need to enable Futures Trading Permission for the api key', which is useful auth context. However, it fails to specify when to use this over similar endpoints like get_sapi_v1_algo_futures_historical_orders or get_sapi_v1_algo_futures_sub_orders.

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

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

With no annotations provided, the description carries the full burden and discloses Weight(IP): 1 (rate limiting), the Base URL, and the return structure (total, executedQty, executedAmt). It also flags the USER_DATA classification and permission requirements.

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?

Information density is appropriate but formatting is awkward with bullet points embedded in prose after an em-dash. All sentences provide value (auth, weight, returns), though front-loading could be improved.

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?

Compensates well for the lack of structured output schema by documenting the return object structure inline. Covers authentication, rate limits, and pagination parameters. Only gap is the conceptual definition of 'sub orders' versus parent algo orders.

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

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

Input schema has 100% description coverage (page, algoId, pageSize constraints, timestamp format, etc.), establishing baseline 3. The description does not add parameter-specific semantics beyond what the schema already provides.

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

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

States 'Query Sub Orders (USER_DATA)' with the specific domain identified via 'Futures Trading Permission' requirement, distinguishing it from the Spot variant sibling. However, it does not clarify what constitutes a 'sub order' in the algo trading context or differentiate from siblings like get_sapi_v1_algo_futures_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?

Provides a clear prerequisite (Futures Trading Permission required) but lacks explicit guidance on when to use this tool versus alternatives like get_sapi_v1_algo_futures_historical_orders or get_sapi_v1_algo_futures_open_orders.

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

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

With no annotations provided, the description carries the full burden and successfully discloses the rate limit weight ('Weight(IP): 1') and the complete return structure JSON since no output schema exists. It misses explicit classification as read-only/safe, though 'Query' implies this, and doesn't mention pagination behavior explicitly.

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 structured with two distinct sections (main description and PREREQUISITE). Every sentence provides value—defining the operation, rate limits, return structure, and prerequisites. The JSON return structure is slightly dense but informationally dense without 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?

Given the lack of output schema and annotations, the description compensates well by documenting the return structure inline and providing prerequisite workflow information. It appropriately covers the 9-parameter complexity, though it could explicitly mention pagination support (page/pageSize parameters).

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

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

The input schema has 100% description coverage (e.g., 'Trading symbol, e.g. BNBUSDT', 'UTC timestamp in ms'), establishing a baseline of 3. The description adds minimal parameter-specific context beyond implicitly clarifying that 'symbol' refers to SPOT trading pairs through the TWAP context.

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

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

The description explicitly states 'Query Historical Algo Orders — Get all historical SPOT TWAP orders', providing a specific verb (Query/Get), resource (historical SPOT TWAP orders), and scope. It clearly distinguishes from siblings like get_sapi_v1_algo_futures_historical_orders (by specifying SPOT) and get_sapi_v1_algo_spot_open_orders (by specifying historical).

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 PREREQUISITE section provides explicit workflow guidance ('First call exchange info or symbol listing...'), indicating when preparatory steps are needed. However, it lacks explicit 'when not to use' guidance or direct references to alternatives like the open orders endpoint for non-historical queries.

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

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

Without annotations, the description carries full behavioral disclosure burden. It documents the return structure (crucial since no output schema exists) and rate-limit weight ('Weight(IP): 1'), but fails to explicitly state read-only safety, authentication requirements beyond parameter names, or error behaviors. The term 'Query' implies read-only but this is not explicit.

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

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

Dense but efficient single-line format front-loaded with action ('Query...'). Every segment earns its place: purpose declaration, scope restriction (SPOT TWAP), operational constraint (Weight), and return structure. The return object syntax is lengthy but necessary given the absence of an output schema.

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

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

Given the absence of both annotations and structured output schema, the description compensates adequately by documenting the return object structure ({ total: number, orders: {...} }). Combined with complete input schema coverage, this provides sufficient context for a query tool, though explicit auth/safety statements would improve it further.

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

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

Input schema has 100% description coverage (signature, timestamp, recvWindow all documented). The description adds no parameter-specific semantics beyond what the schema provides, meeting the baseline expectation for high-coverage schemas.

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?

Specific verb+resource combination ('Query Current Algo Open Orders — Get all open SPOT TWAP orders') clearly identifies the tool retrieves active TWAP orders. Explicitly scopes to 'SPOT' (distinguishing from futures siblings like get_sapi_v1_algo_futures_open_orders) and 'TWAP' (distinguishing from other algo types like VP), while 'Current'/'Open' differentiates from historical order queries.

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

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

Provides no explicit guidance on when to use this versus sibling alternatives (e.g., get_sapi_v1_algo_spot_historical_orders for completed orders, or get_sapi_v1_algo_spot_sub_orders for order details). Mentions 'Weight(IP): 1' which implies rate-limiting considerations but does not constitute usage guidance relative to alternatives.

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

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

With no annotations provided, the description carries the full burden. It successfully discloses the rate limit weight (Weight(IP): 1) and partially documents the return structure with field types ({ total: number, executedQty: string... }), compensating for the lack of output schema. However, it omits safety profile (read-only vs destructive), authentication requirements, and pagination 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?

Extremely compact single-sentence structure with information front-loaded ('Query Sub Orders'). Technical metadata (weight, returns) appended efficiently. No redundant or wasted language, though punctuation (em-dashes) is slightly unconventional.

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 lack of annotations and output schema, the description provides essential technical details (rate limit, return fields). However, for a 6-parameter algo-trading tool, it lacks context on what constitutes a 'sub order', error handling behavior, or the relationship between sub-orders and parent algo orders.

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

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

Schema description coverage is 100%, establishing a baseline of 3. The description reinforces the primary filter parameter ('for a specified algoId') but does not add additional semantic context beyond what the schema already provides for page, pageSize, timestamp, signature, or recvWindow.

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

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

The description clearly states it queries sub-orders for a specified algoId using the verb 'Get'. It distinguishes this tool from siblings like 'historical_orders' or 'open_orders' by specifying 'sub orders', though it fails to explicitly mention 'spot' (vs futures) in the description text itself, relying solely on the tool name for that distinction.

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

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

No guidance provided on when to use this versus get_sapi_v1_algo_spot_historical_orders or get_sapi_v1_algo_spot_open_orders. No mention of prerequisites (e.g., needing a valid algoId from a parent order) or conditions for use.

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

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

No annotations provided, so description carries full burden. Discloses USER_DATA (authentication required), Weight(IP): 1 (rate limiting cost), and provides concrete return structure example showing depositStatus, withdrawStatus, and fee fields. Does not explicitly state read-only nature.

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?

Information is front-loaded but formatting is cluttered. The return value JSON is inlined as a dense blob, and 'Asset Detail' prefix restates the function name. All sentences serve a purpose but structure could be cleaner.

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

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

Despite no formal output schema, description provides detailed return value example showing the nested structure with withdrawal and deposit fields. Covers authentication type, rate limits, and scope limitations comprehensively.

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 has 100% description coverage with all 4 parameters documented. Description does not add semantic meaning beyond schema definitions, warranting baseline score.

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

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

States 'Fetch details of assets supported on Binance' with specific verb and resource. Explicitly distinguishes from sibling tool get_sapi_v1_capital_config_getall by stating network/deposit/withdraw details should come from that alternative instead.

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?

Explicitly states when NOT to use this tool: 'Please get network and other deposit or withdraw details from GET /sapi/v1/capital/config/getall', clearly directing to the correct alternative for those specific data 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?

No annotations are provided, so the description carries the full burden. It discloses the rate limit weight ('Weight(IP): 10') and provides the complete return structure inline since no output schema exists. However, it fails to mention safety characteristics (read-only), error conditions, or data retention limits.

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

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

The description is a single dense sentence mixing title-like text, technical metadata (Weight IP), and JSON return structures. While not verbose, it lacks proper structure and front-loading of the most important information (the return schema appears at the end).

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 tool with 7 parameters and authentication requirements, the description partially compensates for missing output schema by documenting the return structure. However, it lacks explanation of pagination behavior (despite including 'total'), rate limit implications, or authentication requirements beyond the 'USER_DATA' label.

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 100% schema description coverage, the baseline is 3. The description adds minimal semantic value beyond the schema, merely implying that the 'asset' parameter filters dividends by asset type. No additional context is provided for timestamp/signature requirements or time range semantics.

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

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

The description clearly identifies the tool's purpose with the verb 'Query' and resource 'asset Dividend Record'. It distinguishes from sibling asset tools (like get_sapi_v1_asset_asset_detail) by specifying 'Dividend'. However, it buries this under technical metadata like '(USER_DATA)' and 'Weight(IP): 10', slightly reducing 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?

No usage guidelines are provided. There is no indication of when to use this tool versus other asset history tools, no prerequisites mentioned (beyond implied auth), and no guidance on time range constraints or pagination behavior despite the 'total' field in returns.

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

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

With no annotations provided, the description carries the full burden. It discloses the rate limit weight ('Weight(UID): 5') and authentication scope ('USER_DATA'). It also includes an inline return structure description (total/rows), compensating for the lack of output schema. However, it omits safety details like read-only nature, pagination limits, or error scenarios.

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 packed into a single line with a consistent structure: Action (AuthType) — RateLimit Returns: {Schema}. No extraneous words. Minor readability issues due to density, but information is front-loaded with the operation type.

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 10-parameter paginated query with no output schema, the description provides the essential return structure inline and identifies the operation type. However, it lacks explanation of the convert transfer domain model, pagination behavior details, and filtering logic (e.g., how 'asset' matches both deducted and target assets).

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

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

The input schema has 100% description coverage, documenting all 10 parameters including constraints like 'Max:100' for size and 'cannot be greater than 60000' for recvWindow. The description adds no additional parameter semantics beyond the schema, meeting the baseline expectation when schema coverage is comprehensive.

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

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

The description clearly states the action ('Query') and resource ('Convert Transfer'), and the tool name indicates pagination ('by_page'). It distinguishes from the sibling 'post_sapi_v1_asset_convert_transfer' by being a read/query operation. However, it assumes familiarity with 'Convert Transfer' as a Binance-specific feature without explaining the business concept.

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

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

No guidance provided on when to use this tool versus alternatives like 'get_sapi_v1_convert_trade_flow' or 'get_sapi_v1_asset_transfer'. Does not mention prerequisites such as requiring the 'startTime' and 'endTime' parameters to be within valid ranges, or that this queries historical convert transfers specifically.

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

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

Without annotations, the description carries the burden of disclosing behavioral traits. It successfully includes the rate limit weight (60) and the complete return structure inline (total/rows format), which compensates for the missing output schema. However, it lacks details on pagination behavior, error cases, or the specific semantics of 'delegation' versus regular transfers.

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

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

The description is a dense, run-on sentence that repeats 'Query User Delegation History' twice. It crams metadata (USER_DATA, Weight(IP), return JSON) into a single string without clear structure, making it difficult to parse despite being information-dense.

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 10 parameters, no annotations, and no output schema, the description partially compensates by providing the return structure inline. However, it fails to explain business logic (what constitutes a 'delegation' transfer), pagination patterns, or authentication requirements beyond the 'USER_DATA' tag.

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

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

The input schema has 100% description coverage, documenting all 10 parameters including constraints like 'Default:10 Max:100' for size. The description adds no additional parameter semantics (e.g., valid values for 'type', timestamp format details), meeting the baseline expectation when schema coverage is complete.

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 tool queries 'User Delegation History' and specifies it is 'For Master Account', which provides scope. However, it does not explain what 'delegation' means in this context (custody transfers) or clearly distinguish this from sibling transfer history tools like get_sapi_v1_asset_transfer.

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 mentions '(For Master Account)' implying a scope restriction, but provides no explicit guidance on when to use this tool versus other transfer/history endpoints, nor does it mention prerequisites or alternatives.

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

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

Without annotations, the description carries the burden of disclosing behavioral traits. It provides the rate limit 'Weight(IP): 1' and documents the complex nested return structure in detail, which compensates partially for the missing output schema. However, it omits safety context (read-only nature, authentication requirements) beyond the 'USER_DATA' label.

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