Binance.US MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
The tool set covers distinct areas like account info, trading, staking, and custodial operations, but there is significant overlap and ambiguity within categories. For example, multiple tools for OCO orders (binance_us_new_oco, binance_us_get_oco, binance_us_open_oco, binance_us_all_oco_orders) and custodial transfers (binance_us_cust_transfer, binance_us_custodial_custodian_transfer, binance_us_custodial_wallet_transfer) have similar purposes, making it easy for an agent to misselect. Descriptions help clarify, but the sheer number of similar tools creates confusion.
Naming Consistency5/5
Tool names follow a highly consistent snake_case pattern with a clear binance_us_prefix, using verb_noun conventions like get_order, cancel_order, and create_listen_key. There are no deviations in style (e.g., no camelCase or mixed conventions), making the naming predictable and readable throughout the set.
Tool Count2/5
With 93 tools, the count is excessive for a single server, indicating poor scoping. While Binance.US has a broad API, many tools are redundant (e.g., multiple custodial balance tools) or highly specialized (e.g., credit line alerts), creating an overwhelming surface that will be difficult for agents to navigate efficiently. A more modular approach with separate servers for different domains would be more appropriate.
Completeness5/5
The tool set provides comprehensive coverage of the Binance.US API domain, including account management, trading (spot, OCO, OTC), market data, staking, custodial operations, sub-accounts, and withdrawals. There are no obvious gaps; it supports full CRUD/lifecycle operations for each area (e.g., create, get, cancel orders) and handles edge cases like testing and maintenance checks, ensuring agents can perform all necessary workflows without dead ends.
Average 3.8/5 across 93 of 93 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Returns up to 1000 orders,' which hints at a limit, but doesn't cover critical aspects like whether this is a read-only operation, requires authentication, has rate limits, or involves pagination. For a tool that likely accesses sensitive order history, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of just two sentences that directly state the tool's purpose and a key behavioral constraint ('Returns up to 1000 orders'). There is no wasted language, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial API tool with no annotations and no output schema, the description is insufficient. It lacks details on authentication needs, rate limits, error handling, and the structure of returned data (e.g., order fields). For a tool that likely requires secure access and returns historical order data, this leaves too many unknowns for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, fully documenting all 5 parameters with clear constraints (e.g., 'Cannot be used with fromId'). The description adds no additional parameter semantics beyond what's in the schema, such as explaining the purpose of 'recvWindow' or typical use cases for the parameters. Given the high schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all OCO orders (history) on Binance.US.' It specifies the verb ('Get'), resource ('OCO orders'), and scope ('all' and 'history'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'binance_us_get_oco' or 'binance_us_open_oco', which might handle specific or active OCO orders, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention any prerequisites, such as authentication requirements, or compare it to similar tools like 'binance_us_get_oco' (which might fetch a single OCO order) or 'binance_us_open_oco' (which might list active OCO orders). Without this context, users may struggle to choose the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return data (price, quantity, etc.) but lacks critical details: authentication requirements (likely needed for personal trade data), rate limits, pagination behavior (implied by 'limit' parameter but not explained), error handling, or whether it's read-only. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: two sentences that directly state the tool's function and return data. Every word earns its place, with no redundant or vague phrasing. It efficiently communicates the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (personal trade data retrieval with 7 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't address authentication needs, rate limits, error cases, or detailed return structure (beyond high-level fields). For a tool likely requiring API keys and returning sensitive data, this leaves critical gaps for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 7 parameters. The description adds no additional parameter semantics beyond implying filtering by trading pair ('specific trading pair'), which is already covered by the 'symbol' parameter in the schema. This meets the baseline for high schema coverage, but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get trade history for a specific trading pair.' It specifies the verb ('Get') and resource ('trade history'), and distinguishes it from siblings like 'binance_us_historical_trades' by focusing on personal trades rather than market-wide data. However, it doesn't explicitly differentiate from 'binance_us_cust_trade_history', which might be a similar sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., authentication needs), compare it to sibling tools like 'binance_us_cust_trade_history' or 'binance_us_historical_trades', or specify use cases beyond retrieving trade history. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the order types supported but fails to describe critical traits: this is a financial transaction tool that likely requires authentication, may incur fees, affects account balances, and has irreversible effects (e.g., market orders execute immediately). The description lacks warnings about risks, rate limits, or response formats, which are essential for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and lists order types without unnecessary details. However, it could be slightly more structured by separating the action from the supported features for better readability, but it avoids redundancy and stays focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (14 parameters, financial transactions), lack of annotations, and no output schema, the description is insufficient. It doesn't cover behavioral risks, authentication needs, error handling, or return values, leaving significant gaps for an AI agent to operate this tool safely and effectively in a trading context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 14 parameters thoroughly with descriptions and enums. The description adds minimal value by listing order types, which partially overlaps with the 'type' parameter's enum. It doesn't explain parameter interactions (e.g., 'quantity' vs. 'quoteOrderQty') or provide usage examples, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Place a new trade order') and resource ('on Binance.US'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'binance_us_test_order' or 'binance_us_cust_new_order', which appear to serve similar functions but for different contexts (test vs. custodial accounts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling tools (e.g., 'binance_us_test_order' for testing, 'binance_us_cust_new_order' for custodial accounts), there's no indication of prerequisites, target scenarios, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but does not address authentication needs, rate limits, error handling, or the format of returned data. This is a significant gap for a tool interacting with a financial API.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and efficiently communicates the core functionality, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of interacting with a Binance.US API for OCO orders, the description is insufficient. No annotations exist, and there is no output schema, so the agent lacks information on authentication, rate limits, error scenarios, and the structure of returned data. The description does not compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with one parameter ('recvWindow') fully documented in the schema. The description does not add any additional meaning or context about parameters beyond what the schema provides, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('all open OCO orders on Binance.US'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'binance_us_all_oco_orders' or 'binance_us_open_orders', which might handle similar data, so it lacks full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as 'binance_us_all_oco_orders' or 'binance_us_open_orders'. It does not mention any prerequisites, exclusions, or specific contexts for usage, leaving the agent without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'price change statistics' but doesn't disclose behavioral traits like whether this is a read-only operation, rate limits, authentication needs, error handling, or response format. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence earns its place by specifying the action, resource, and key parameter constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'price change statistics' includes (e.g., percentage change, volume), how results are returned, or any limitations. For a tool with 4 parameters and no structured output information, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal value by mentioning 'custom window sizes' which aligns with the 'windowSize' parameter but doesn't provide additional semantics beyond what the schema already specifies. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('rolling window price change statistics') with specific scope ('custom window sizes (1m to 7d)'). It distinguishes from siblings by focusing on price change statistics rather than trades, orders, or account information, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'ticker_24hr' or 'klines' is provided. The description mentions window sizes but doesn't specify use cases, prerequisites, or exclusions, leaving the agent with minimal context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool retrieves a 'status list' but doesn't specify whether this is a read-only operation, if it requires authentication, rate limits, or what the output format looks like. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. It avoids redundancy and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 is incomplete. It doesn't cover behavioral aspects like authentication needs, rate limits, or output structure, which are crucial for a tool interacting with a financial API. While the schema covers parameters well, the overall context is insufficient for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('email' and 'recvWindow'). The description doesn't add any additional meaning beyond the schema, such as explaining optionality or usage examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get status list of sub-accounts including activation status and enabled features.' It specifies the verb ('Get'), resource ('status list of sub-accounts'), and scope ('activation status and enabled features'). However, it doesn't explicitly differentiate from sibling tools like 'binance_us_subaccount_list' or 'binance_us_subaccount_summary', which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites, such as authentication requirements, or compare it to similar tools like 'binance_us_subaccount_list' or 'binance_us_subaccount_summary' that might overlap in functionality. This lack of context makes it harder for an agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states a read operation ('Get'), implying it's likely non-destructive, but doesn't mention authentication needs, rate limits, error conditions, or the format of the returned data (e.g., whether it's paginated, as suggested by the 'page' and 'size' parameters). This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without any wasted words. It's front-loaded with the essential information, making it easy to parse and understand quickly, which is ideal for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial API tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address behavioral aspects like authentication, rate limits, or data format, and while the schema covers parameters, the overall context for safe and effective use is lacking. This makes it incomplete for a tool in this domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all parameters (email, page, size, recvWindow). The description adds no additional meaning beyond what's in the schema, such as explaining how filtering by email works or the implications of pagination. Baseline 3 is appropriate when the schema does the heavy lifting, but the description doesn't compensate with extra insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'total USD value of assets in the master account and all sub-accounts', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'binance_us_subaccount_assets' or 'binance_us_subaccount_list', which might provide overlapping or related information about sub-accounts, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as other subaccount-related tools in the sibling list. It lacks context on prerequisites, timing, or exclusions, leaving the agent to infer usage based on the purpose alone without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 but only states the basic function. It doesn't cover critical aspects like whether this is a read-only operation (implied by 'Get' but not explicit), authentication requirements, rate limits, pagination behavior (beyond what's in the schema), error handling, or the format of returned data. This leaves significant gaps for an agent to understand how to invoke it safely and effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the essential information without any wasted words. It efficiently conveys the core purpose, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no output schema, and no annotations), the description is incomplete. It lacks details on behavioral traits (e.g., authentication, rate limits), output format, and usage context, which are crucial for an agent to operate this tool correctly in a financial API environment. The high schema coverage helps with inputs, but overall guidance remains insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are documented in the input schema itself (e.g., 'email' filters by sub-account, 'startTime' and 'endTime' define a range in milliseconds). The description adds no additional parameter context beyond implying a historical query, so it meets the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('transfer history between master and sub-accounts'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'binance_us_subaccount_transfer' (which likely performs transfers) or 'binance_us_custodial_custodian_transfer_history' (which might involve custodial transfers), leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description doesn't mention prerequisites (e.g., authentication needs), typical use cases, or how it differs from similar history tools in the sibling list, such as 'binance_us_cust_transfer_history' or 'binance_us_cl_transfer_history'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Get' and 'price change statistics,' implying a read-only operation, but fails to detail critical aspects like rate limits, authentication requirements, error handling, or the format of returned data. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and efficient, making it easy for an agent to quickly grasp the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 is incomplete for effective tool use. It doesn't explain what data is returned (e.g., fields like price change, volume), how to handle multiple symbols, or any dependencies or limitations. For a tool with no structured behavioral hints, this minimal description leaves too many unknowns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are documented in the input schema. The description does not add any additional meaning or context beyond what the schema provides, such as examples of valid symbols or implications of the 'type' parameter. This meets the baseline for high schema coverage but doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('24-hour rolling window price change statistics'), which is specific and informative. However, it doesn't explicitly distinguish this tool from similar siblings like 'binance_us_ticker_price' or 'binance_us_rolling_window', which might also provide price-related data, leaving some ambiguity about its unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as other ticker or price-related tools in the sibling list. It lacks context about scenarios where 24-hour statistics are preferred over other metrics, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 implies a read-only operation ('Get'), but doesn't specify critical details like whether authentication is required, rate limits, or the format of returned data (e.g., JSON structure). For a financial API tool, this omission is significant, as the agent lacks context on safety and performance traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part ('Get best bid/ask prices and quantities (top of book)') contributes directly to understanding the tool's function, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial API tool with no annotations and no output schema, the description is incomplete. It lacks details on authentication requirements, rate limits, error handling, and the structure of returned data (e.g., bid/ask arrays). For a tool that likely returns real-time market data, this gap could hinder effective agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the two parameters ('symbol' and 'symbols') and their mutual exclusivity. The description adds no additional parameter semantics beyond implying the tool fetches data for specified symbols. This meets the baseline score of 3, as the schema handles the heavy lifting without description enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('best bid/ask prices and quantities'), specifying it's for the 'top of book'. It distinguishes from siblings like 'binance_us_ticker_24hr' or 'binance_us_ticker_price' by focusing on order book depth rather than aggregated metrics. However, it doesn't explicitly differentiate from 'binance_us_order_book', which might offer more depth, making it slightly less specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'binance_us_order_book' or 'binance_us_ticker_price'. The description lacks context such as use cases (e.g., for real-time market depth analysis) or prerequisites (e.g., no authentication needed). This leaves the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It states what the tool does but doesn't describe response format, rate limits, authentication requirements, error conditions, or whether it's a real-time or cached price. For a financial data tool with zero annotation coverage, this represents significant behavioral transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words, front-loading the essential information ('Get latest price') immediately. Every word earns its place, with no redundant or unnecessary information. The structure is optimal for a simple data retrieval tool, though this conciseness comes at the expense of completeness in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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, plus the financial data context, the description is insufficiently complete. It doesn't explain what format the price data returns (single value vs. structured object), whether it includes timestamp information, how current 'latest' actually is, or any limitations. For a price data tool in a complex financial API ecosystem, more context would be valuable despite the simple parameter structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, with both parameters ('symbol' and 'symbols') clearly documented as mutually exclusive options for specifying trading pairs. The description adds no additional parameter information beyond what's in the schema, but since schema coverage is complete, the baseline score of 3 is appropriate. The description's mention of 'symbol(s)' aligns with but doesn't enhance the schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get latest price') and target ('for symbol(s)'), making the purpose immediately understandable. It distinguishes itself from siblings like 'binance_us_ticker_24hr' or 'binance_us_avg_price' by focusing specifically on current price retrieval rather than historical or aggregated data. However, it doesn't explicitly mention the exchange context (Binance US) which is implied by 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.
Usage Guidelines2/5
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. With many sibling tools like 'binance_us_ticker_24hr' (24-hour statistics), 'binance_us_avg_price' (average price), and 'binance_us_order_book' (order book data), there's no indication of when this specific price retrieval tool is most appropriate. The description lacks any context about use cases, prerequisites, or comparisons to similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but reveals minimal behavioral traits. It mentions filtering but doesn't disclose pagination behavior (implied by offset/limit parameters), authentication requirements, rate limits, error conditions, or whether this is a read-only operation. The agent must infer behavior from parameter names alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with zero wasted words. Every word earns its place: 'Get' (action), 'crypto withdrawal history' (resource), and three filter examples that hint at capability scope. Perfectly front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial API tool with 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address authentication requirements (critical for withdrawal data), rate limits, error handling, response format, or pagination strategy. The agent lacks necessary context for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds marginal value by mentioning three filter types (coin, status, time range) but doesn't explain parameter interactions, default behaviors beyond what's in schema descriptions, or the meaning of 'recvWindow'. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('crypto withdrawal history') with specific filtering capabilities. It distinguishes from deposit-related siblings like 'binance_us_deposit_history' but doesn't explicitly differentiate from other withdrawal tools like 'binance_us_withdraw_crypto' or 'binance_us_withdraw_fiat'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description mentions filtering capabilities but doesn't specify prerequisites (e.g., authentication needs), typical use cases, or when to choose this over other withdrawal-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states what data is retrieved without mentioning behavioral traits like rate limits, authentication needs, or response format. It doesn't disclose if this is a read-only operation or any constraints beyond the aggregation logic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and adds a clarifying detail about aggregation criteria. There is no wasted verbiage, making it appropriately sized for its function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is minimal but covers the basic purpose. However, for a tool with 5 parameters and no structured behavioral hints, it lacks details on usage context, return values, or error handling, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond what the schema provides, such as explaining how 'fromId' relates to aggregation or trade ordering. Baseline 3 is appropriate as the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'compressed aggregate trades', specifying what the tool does. It distinguishes from siblings like 'recent_trades' or 'historical_trades' by mentioning aggregation based on time, order, and price, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'recent_trades' or 'historical_trades' is provided. The description implies usage for aggregated trade data but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'Returns order history,' which implies a read-only operation, but it doesn't specify whether authentication is required, if there are rate limits, or what the return format looks like (e.g., pagination, structure). For a tool with no annotations and potential complexity (6 parameters), this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: two sentences that directly state the tool's purpose and return value. There is no wasted language or redundancy, making it easy for an agent to parse quickly. Every sentence earns its place by providing essential information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and return type but lacks details on authentication, error handling, rate limits, and output structure. While it meets a bare minimum for a read operation, it doesn't provide enough context for the agent to use the tool effectively in all scenarios, especially compared to siblings with overlapping functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing clear details for all 6 parameters (e.g., symbol, orderId, limit with default/max values). The description adds no additional parameter semantics beyond what's in the schema, such as explaining relationships between parameters (e.g., that orderId, startTime, and endTime are optional filters). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all orders (active, canceled, or filled) for a symbol on Binance.US.' It specifies the verb ('Get'), resource ('orders'), and scope ('all orders' including statuses). However, it doesn't explicitly differentiate from sibling tools like 'binance_us_open_orders' or 'binance_us_order_history' tools, which is why it doesn't achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention sibling tools like 'binance_us_open_orders' (for active orders only) or 'binance_us_my_trades' (for trade history), nor does it specify prerequisites such as authentication requirements. This lack of comparative context leaves the agent with insufficient information to choose appropriately among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It specifies the time window ('5-minute rolling weighted average') but doesn't mention rate limits, authentication needs, error handling, or the format of the response. For a tool with no annotation coverage, this leaves significant gaps in understanding its operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information ('Get current 5-minute rolling weighted average price') with no wasted words. It's appropriately sized for a simple tool with one parameter, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally complete but lacks depth. It covers the basic purpose and parameter context but omits behavioral details like response format or error cases. For a read-only price-fetching tool, this is adequate but not thorough, as it relies heavily on the schema for parameter info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'symbol' parameter clearly documented. The description doesn't add any extra semantic details beyond what the schema provides, such as examples of valid symbols or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('current 5-minute rolling weighted average price'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'binance_us_ticker_price' or 'binance_us_rolling_window', which might also provide price-related data, leaving some ambiguity about uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as other price-fetching tools in the sibling list. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage based on the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'Returns OHLCV data,' which indicates a read-only operation, but does not specify other important traits such as rate limits, authentication needs, error handling, or whether it's a public or private API endpoint. For a financial data tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of only two sentences that directly state the tool's purpose and output. Every word earns its place with no redundancy or unnecessary details, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and output but lacks context on usage guidelines, behavioral traits, and integration with sibling tools. Without an output schema, it does not detail the structure of returned OHLCV data, which could be important for downstream processing. This results in a description that meets the minimum viable standard but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are well-documented in the input schema with descriptions and constraints (e.g., 'symbol' as trading pair, 'interval' with enum values, 'limit' with default and max). The description adds no additional parameter semantics beyond what the schema provides, such as examples of valid symbol formats or time range best practices. Given the high schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get Kline/candlestick data for a trading pair. Returns OHLCV data.' It specifies the verb ('Get'), resource ('Kline/candlestick data'), and output type ('OHLCV data'), which is specific and informative. However, it does not explicitly differentiate this tool from sibling tools like 'binance_us_historical_trades' or 'binance_us_recent_trades', which might also retrieve trading data, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention any prerequisites, such as authentication requirements, or compare it to other data retrieval tools in the sibling list (e.g., 'binance_us_historical_trades' for historical trades or 'binance_us_ticker_24hr' for 24-hour ticker data). Without such context, an AI agent might struggle to choose the appropriate tool for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying it's likely read-only, but doesn't confirm this or mention any authentication requirements, rate limits, error conditions, or what the output format looks like (e.g., JSON structure). For a tool accessing financial data with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently conveys the essential information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (accessing sub-account financial data), lack of annotations, and no output schema, the description is minimally adequate but incomplete. It covers the basic purpose but misses behavioral details like authentication needs, rate limits, and output format, which are critical for an AI agent to use this tool effectively in a financial context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('email' and 'recvWindow') well-documented in the schema. The description doesn't add any additional meaning beyond what's in the schema (e.g., it doesn't explain why 'email' is required or typical use cases for 'recvWindow'), so it meets the baseline score when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('asset balances for a specific sub-account'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'binance_us_subaccount_summary' or 'binance_us_custodial_balance', which might also provide balance-related information, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling tools related to balances and sub-accounts (e.g., 'binance_us_subaccount_summary', 'binance_us_custodial_balance'), there's no indication of what makes this tool unique or when it should be preferred over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 warns '⚠️ This moves funds between accounts!', indicating a destructive operation, which is helpful. However, it lacks critical details such as authentication requirements, rate limits, whether the transfer is reversible, confirmation steps, or error handling, leaving significant gaps for a financial transaction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and includes a warning in the second. It's efficient with two sentences, though the warning could be more specific (e.g., 'irreversible' or 'requires 2FA'). No wasted words, but slight room for improvement in clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial transfer tool with no annotations and no output schema, the description is insufficient. It lacks details on authentication, security measures (e.g., 2FA), transfer limits, response format, error cases, and idempotency. The warning is a start, but more context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no additional parameter semantics beyond what the schema provides (e.g., it doesn't clarify email formats, asset symbol constraints, or amount precision). The baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Execute an asset transfer') and the resources involved ('between master account and a sub-account'). It distinguishes itself from sibling tools like 'binance_us_subaccount_assets' (which retrieves assets) and 'binance_us_subaccount_transfer_history' (which retrieves history) by focusing on the execution of transfers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., authentication requirements), nor does it differentiate from similar tools like 'binance_us_custodial_custodian_transfer' or 'binance_us_cust_transfer', leaving the agent to infer usage context from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the atomic nature of the operation and its utility for modification, but fails to disclose critical behavioral traits such as authentication requirements, rate limits, error handling (e.g., what happens if the cancel or new order fails), or the response format. For a complex trading tool with 19 parameters and no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of only two sentences that directly state the tool's purpose and utility. Every sentence earns its place by clearly conveying the core functionality without any redundant or verbose language. It is appropriately sized for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (19 parameters, trading operation), lack of annotations, and no output schema, the description is incomplete. It adequately explains the purpose but fails to provide necessary context such as behavioral details (e.g., side effects, error handling), usage constraints, or output expectations. For a tool of this nature, more comprehensive information is needed to guide an AI agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are documented in the input schema with descriptions and enums. The description does not add any additional semantic information about parameters beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline score is 3, as the description does not need to compensate but also does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Cancel an existing order and place a new order on the same symbol atomically. This is useful for modifying order parameters.' It specifies the verb (cancel and place) and resource (order), but does not explicitly differentiate from sibling tools like 'binance_us_cancel_order' or 'binance_us_new_order', which handle these actions separately. The atomic nature is highlighted, but sibling distinction is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by stating 'This is useful for modifying order parameters,' suggesting it should be used when updating an existing order rather than creating a new one from scratch. However, it does not explicitly mention when to use this tool versus alternatives like 'binance_us_cancel_order' followed by 'binance_us_new_order', nor does it specify prerequisites or exclusions. The guidance is helpful but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'Get[s] a deposit address' but doesn't disclose behavioral traits like whether this requires authentication, if it's idempotent, rate limits, or what the return format is (e.g., address string, network details). For a financial tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the core purpose and usage. Every word earns its place, with no redundancy or fluff, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial deposit tool with no annotations and no output schema, the description is incomplete. It lacks details on authentication needs, error handling, return values, or any behavioral constraints. While concise, it doesn't provide enough context for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (coin, network, recvWindow) with descriptions. The description adds no additional parameter semantics beyond implying 'crypto asset' relates to 'coin' and 'network'. Baseline is 3 since the schema does the heavy lifting, but the description doesn't compensate with extra context like format examples or dependencies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a deposit address') and target resource ('for a specific crypto asset'), with the purpose of receiving funds into a Binance.US account. It doesn't explicitly differentiate from sibling tools like 'binance_us_withdraw_crypto' or 'binance_us_deposit_history', but the verb 'Get' and context of receiving funds make its role reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to receive funds into a Binance.US account, but provides no explicit guidance on when to use this versus alternatives (e.g., vs. checking deposit history or withdrawing). It mentions the purpose ('to receive funds'), which gives some contextual hint, but lacks clear when/when-not statements or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it indicates this is a read operation ('Get'), it doesn't mention authentication requirements, rate limits, error conditions, or what the response format looks like. For a financial API tool with no annotation coverage, this represents significant gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that communicates the core functionality and filtering options without any wasted words. It's front-loaded with the main purpose and efficiently lists the filtering capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial API tool with 7 parameters and no annotations or output schema, the description is insufficient. It doesn't address authentication requirements, rate limits, error handling, response format, or pagination behavior. The tool's complexity demands more comprehensive documentation than what's provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions filtering by 'coin, status, or time range' which maps to three of the seven parameters. However, with 100% schema description coverage, the schema already documents all parameters thoroughly. The description adds minimal value beyond what's in the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('crypto deposit history'), making the purpose immediately understandable. It distinguishes from siblings like 'binance_us_withdraw_history' by focusing on deposits rather than withdrawals, though it doesn't explicitly mention this distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving deposit history with filtering capabilities, but provides no explicit guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like authentication requirements or rate limits that might be relevant for API calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the tool queries an OCO order, implying a read-only operation, but doesn't disclose behavioral traits such as authentication requirements, rate limits, error handling, or what the response includes. This leaves significant gaps for an agent to understand how to invoke it correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose, and the second provides critical parameter guidance. It's front-loaded and appropriately sized for a simple query tool, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that likely involves API calls with authentication and rate limits. It covers the basic purpose and parameter requirement but lacks details on behavior, response format, or error conditions, which are essential for an agent to use it effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (orderListId, origClientOrderId, recvWindow). The description adds minimal value by emphasizing the 'either/or' requirement for the first two parameters, but doesn't provide additional context like format examples or usage scenarios beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('a specific OCO order on Binance.US'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'binance_us_all_oco_orders' (which likely lists all OCO orders) or 'binance_us_get_order' (which queries regular orders), missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage by stating 'Either orderListId or origClientOrderId must be provided,' which suggests when to use this tool (when you have one of these IDs). However, it lacks explicit guidance on when to choose this over alternatives like 'binance_us_all_oco_orders' or 'binance_us_get_order,' and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the response structure (total, rows, order details) which is helpful, but lacks critical behavioral details: it doesn't specify if this is a read-only operation (implied but not stated), whether authentication is required, rate limits, pagination behavior beyond parameters, or error conditions. For a query tool with no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized: it starts with the core purpose, provides usage guidance, and details the response format. Every sentence adds value, though the response details could be slightly more concise. It's front-loaded with key information, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 optional parameters, no output schema, no annotations), the description is adequate but has clear gaps. It covers the purpose and response format, but lacks behavioral context (e.g., auth needs, rate limits) and doesn't fully compensate for the missing output schema. For a query tool in a financial API context, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 7 parameters. The description adds minimal value beyond the schema: it mentions 'optional filters' and 'various filtering options', which aligns with the schema but doesn't provide additional syntax, examples, or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Query all OTC (Over-The-Counter) trade orders with optional filters' and 'retrieve your OTC trading history'. It specifies the resource (OTC trade orders) and action (query/retrieve), but doesn't explicitly differentiate from sibling tools like 'binance_us_otc_get_order' or 'binance_us_all_orders', which might handle different order types or retrieval methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context: 'Use this to retrieve your OTC trading history with various filtering options.' It suggests this is for historical OTC orders with filtering, but doesn't explicitly state when to use it versus alternatives like 'binance_us_otc_get_order' (likely for single orders) or 'binance_us_all_orders' (likely for non-OTC orders). No explicit when-not-to-use or prerequisite guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the OCO mechanism ('When one triggers, the other is automatically cancelled'), which is useful behavioral context. However, it lacks critical details like authentication requirements, rate limits, error handling, or what happens on partial fills. For a trading tool with no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences. The first sentence states the purpose, the second explains OCO mechanics, and the third provides key usage rules. It is front-loaded with the main action, though the price relationship note could be more integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex trading tool with 16 parameters, no annotations, and no output schema, the description is incomplete. It misses critical context like response format, error conditions, authentication needs, and market impact. The OCO explanation helps, but more behavioral and operational details are needed for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 16 parameters thoroughly. The description adds minimal value beyond the schema by mentioning price relationships for BUY/SELL OCOs, but does not explain parameter interactions or provide additional semantic context. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Place a new OCO order') and resource ('on Binance.US'), and explains what an OCO order is ('combine a limit order with a stop-loss order'). It distinguishes from siblings by focusing on OCO orders specifically, unlike general order tools like 'binance_us_new_order'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for OCO orders but does not explicitly state when to use this tool versus alternatives like 'binance_us_new_order' or 'binance_us_cust_oco_order'. It provides some contextual guidance with price relationship rules for BUY/SELL, but lacks explicit when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions filtering but does not disclose critical traits such as pagination behavior (implied by 'page' and 'limit' parameters), authentication requirements, rate limits, or error handling. For a read operation with multiple parameters, this leaves significant gaps in understanding how the tool behaves beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get a list of all sub-accounts') and adds filtering details without redundancy. Every word serves a purpose, making it appropriately sized and easy to parse, with no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema), the description is incomplete. It covers the basic purpose and filtering but lacks details on behavioral aspects like pagination, authentication, or response format. While concise, it does not provide enough context for safe and effective use, especially without annotations to fill in gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are documented in the input schema. The description adds minimal value by mentioning filtering by 'email or status', which aligns with the schema but does not provide additional context like format examples or usage nuances. With high schema coverage, the baseline score of 3 is appropriate as the description does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('list of all sub-accounts'), making the purpose evident. It distinguishes this tool from sibling tools like 'binance_us_subaccount_assets' or 'binance_us_subaccount_status' by focusing on listing rather than retrieving specific assets or status details. However, it doesn't explicitly differentiate from 'binance_us_subaccount_summary', which might overlap in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning filtering capabilities ('Filter by email or status'), suggesting when to apply these parameters. However, it lacks explicit guidance on when to use this tool versus alternatives like 'binance_us_subaccount_summary' or 'binance_us_subaccount_status', and does not mention prerequisites or exclusions, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 required API key and return content ('Returns transfer history with status, amounts, and timestamps.'), which adds useful context. However, it doesn't cover other behavioral aspects like rate limits, error conditions, pagination details (implied by parameters but not described), or whether it's read-only (implied by 'Get history' but not explicit). The description adds some value but leaves gaps for a mutation-free tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: purpose, prerequisite, and return details. It's front-loaded with the main purpose, and each sentence adds value without redundancy. However, it could be slightly more structured (e.g., bullet points for key points) or refined for optimal clarity, but it's efficient and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no output schema, no annotations), the description is moderately complete. It covers the purpose, prerequisite, and return content, but lacks details on output format (beyond high-level fields), error handling, or sibling differentiation. For a tool with rich parameter documentation but no output schema, it should provide more context on what to expect from the results to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all 8 parameters thoroughly. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., it doesn't explain parameter interactions or provide examples). According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get history of transfers from Binance.US exchange wallet to custodial sub-account.' It specifies the action ('Get history'), resource ('transfers'), and scope ('from Binance.US exchange wallet to custodial sub-account'). However, it doesn't explicitly differentiate from sibling tools like 'binance_us_custodial_custodian_transfer_history' or 'binance_us_cust_wallet_transfer_history', which appear similar based on naming, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite: '⚠️ REQUIRES CUSTODIAL SOLUTION API KEY,' which provides some context for when to use this tool (i.e., when such an API key is available). However, it lacks explicit guidance on when to choose this tool over alternatives (e.g., vs. other transfer history tools in the sibling list) or any exclusions (e.g., when not to use it). The usage is implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool queries order status, implying a read-only operation, but does not mention authentication requirements, rate limits, error conditions, or the format of returned data. For a financial API tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose, and the second provides essential usage guidance. It is front-loaded and appropriately sized, making it easy for an agent to parse quickly without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial API tool with no annotations and no output schema, the description is incomplete. It lacks information on authentication needs, rate limits, error handling, and the structure of returned data, which are critical for effective tool use. While concise, it does not provide enough context for reliable agent operation in this domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters (symbol, orderId, origClientOrderId, recvWindow). The description adds minimal value by noting the requirement for 'Either orderId or origClientOrderId must be provided,' which clarifies a logical constraint not explicit in the schema. This meets the baseline for high schema coverage without significantly enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Query the status') and target resource ('a specific order on Binance.US'), using precise language that distinguishes it from siblings like 'binance_us_all_orders' (which lists multiple orders) or 'binance_us_cancel_order' (which modifies orders). It directly addresses what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by specifying that 'Either orderId or origClientOrderId must be provided,' which helps differentiate it from tools that might not require such identifiers. However, it lacks explicit when-to-use context compared to alternatives like 'binance_us_cust_get_order' or 'binance_us_otc_get_order,' leaving the agent to infer based on naming conventions rather than clear directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the tool 'Shows how many orders you can place within each interval,' which implies a read-only operation, but does not disclose behavioral traits like authentication requirements, rate limits on the tool itself, error conditions, or response format. This leaves significant gaps for a tool that likely requires API access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the main purpose. Every word earns its place by specifying what is retrieved and the scope, with no redundant or vague language, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial API tool with no annotations and no output schema, the description is incomplete. It lacks details on authentication, response structure, error handling, and how the rate limit data is formatted, which are critical for an AI agent to use the tool effectively in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% description coverage, so the baseline is 3. The description adds no parameter-specific information, but since there is only one optional parameter (recvWindow), the tool's core functionality is clear without it. This slight compensation raises the score, as the description effectively conveys the tool's purpose independent of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'current trade order count rate limits for all time intervals', specifying exactly what the tool retrieves. It distinguishes from siblings by focusing on rate limits rather than account info, trades, orders, or other Binance US operations, making its purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention prerequisites, such as authentication needs, or compare it to other tools for rate limit information, leaving the agent without context for selection among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes what information is returned but doesn't disclose behavioral aspects like whether this is a read-only operation (implied by 'Get' but not explicit), authentication requirements, rate limits, pagination, or error conditions. For a tool with no annotation coverage, this represents a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero wasted words. The first sentence establishes the core purpose and key details, while the second adds important supplementary information about network-specific status. Every element earns its place, and the structure is front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with one optional parameter and no output schema, the description adequately covers what information is returned. However, without annotations or output schema, it lacks details about return format, authentication needs, rate limits, or error handling. The description is complete enough for basic understanding but leaves important operational context unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one optional parameter 'recvWindow' fully documented in the schema. The description doesn't mention any parameters or add semantic context beyond what the schema provides. With high schema coverage, the baseline score of 3 is appropriate since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get details' and specifies the resource 'all crypto assets', with explicit details about what information is included: 'fees, withdrawal limits, and network status' plus 'deposit/withdrawal enabled status per network'. It distinguishes from sibling tools like 'binance_us_exchange_info' or 'binance_us_custodial_supported_assets' by focusing specifically on asset-level configuration details rather than general exchange info or custodial assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying what details are retrieved (asset configuration), but doesn't explicitly state when to use this tool versus alternatives like 'binance_us_exchange_info' (which might include broader exchange metadata) or 'binance_us_custodial_supported_assets' (which focuses on custodial services). No explicit 'when-not' guidance or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action is a cancellation, implying a destructive write operation, but does not disclose behavioral traits such as authentication needs, rate limits, error conditions, or what happens upon success. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste. The first sentence states the purpose, and the second adds crucial scope information. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial trading cancellation tool with no annotations and no output schema, the description is minimal. It covers the basic purpose and scope but lacks details on behavior, output, or error handling. It is adequate but has clear gaps for a mutation tool in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description does not add any meaning beyond what the schema provides, such as explaining parameter interactions or examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Cancel an entire OCO order') and the resource ('on Binance.US'), with the second sentence explaining the scope ('Cancelling any individual leg will cancel the entire OCO'). This distinguishes it from sibling tools like 'binance_us_cancel_order' which cancels single orders, not OCO orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for OCO orders, but does not explicitly state when to use this tool versus alternatives like 'binance_us_cancel_all_open_orders' or 'binance_us_cancel_order'. It mentions the effect of cancellation but lacks guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 authentication requirement ('Requires API key with MARKET_DATA permission'), which is useful behavioral context. However, it lacks details on rate limits, response format, pagination, or error handling, leaving gaps for a tool that fetches historical data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste: the first states the purpose, and the second adds critical authentication context. It's front-loaded and appropriately sized, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that fetches historical trades. It covers authentication but misses details on return values, data format, or potential limitations. With 3 parameters and 100% schema coverage, it's adequate but lacks depth for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters like 'symbol', 'limit', and 'fromId'. The description doesn't add any parameter-specific semantics beyond what's in the schema, such as examples or usage tips. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'older historical trades for a trading pair', making the purpose specific and understandable. It distinguishes from siblings like 'binance_us_recent_trades' by specifying 'older historical trades', though it doesn't explicitly name the sibling for comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context with 'Requires API key with MARKET_DATA permission', which implies when to use it based on authentication. However, it doesn't explicitly state when to use this tool versus alternatives like 'binance_us_recent_trades' or 'binance_us_agg_trades', leaving usage somewhat implied rather than clearly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the return data structure (trade ID, price, etc.), which is helpful, but fails to disclose critical behavioral traits such as whether this is a read-only operation, rate limits, authentication requirements, or how 'recent' is defined (e.g., time window). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes essential return details. There is no wasted verbiage, and every part of the sentence adds value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no output schema, no annotations), the description covers the basic purpose and return format adequately. However, it lacks details on behavioral aspects like authentication or rate limits, which are important for API tools. Without annotations or output schema, the description is minimally complete but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('symbol' and 'limit') well-documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as examples for 'symbol' beyond 'BTCUSD' or clarification on 'limit' defaults. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get recent trades') and resource ('for a trading pair on Binance.US'), making the purpose specific and unambiguous. It distinguishes from siblings like 'binance_us_historical_trades' by specifying 'recent' trades, and from 'binance_us_my_trades' by not being user-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving recent trades on Binance.US, but provides no explicit guidance on when to use this tool versus alternatives like 'binance_us_historical_trades' or 'binance_us_agg_trades'. It lacks any mention of prerequisites, exclusions, or specific contexts where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While it correctly indicates this is a destructive operation (canceling orders), it lacks critical behavioral details such as authentication requirements, rate limits, error conditions, or what happens if the order is already filled. The description is minimal and does not compensate for the missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences, both of which are essential: the first states the purpose, and the second provides critical parameter guidance. There is no wasted text, and it is front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial trading operation with no annotations and no output schema, the description is insufficient. It lacks information on authentication, side effects, error handling, and response format. For a tool that performs a potentially irreversible action in a sensitive domain, more contextual detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds minimal value by emphasizing the mutual exclusivity of 'orderId' and 'origClientOrderId', but does not provide additional semantic context beyond what the schema already states. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Cancel') and target resource ('an active order on Binance.US'), which directly matches the tool name. It distinguishes from sibling tools like 'binance_us_cancel_all_open_orders' by focusing on single order cancellation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Cancel an active order') and specifies parameter requirements ('Either orderId or origClientOrderId must be provided'). However, it does not mention when NOT to use it or explicitly differentiate from alternatives like 'binance_us_cancel_replace'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 API key requirement and return format ('settlement history with status, amounts, and timestamps'), which is helpful. However, it doesn't mention pagination behavior (implied by 'page' and 'limit' parameters but not described), rate limits, error conditions, or whether this is a read-only operation (though 'Get history' suggests it is). More behavioral details would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose, followed by a warning and return details. It's efficient with three sentences and no wasted words. However, it could be slightly more structured (e.g., separating warnings into a bullet point), but it's still clear and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no output schema, no annotations), the description is moderately complete. It covers purpose, prerequisites, and return format, but lacks details on pagination, error handling, and behavioral constraints. For a tool with many parameters and no output schema, more context on what the output looks like (beyond 'status, amounts, and timestamps') would be beneficial, though the schema handles inputs well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 8 parameters. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain 'rail' further or provide examples for 'asset'). With high schema coverage, the baseline is 3, as the description doesn't compensate with extra insights but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get history of settlements from custodial sub-account to custodial partner.' It specifies the verb ('Get history') and resource ('settlements'), and distinguishes it from other settlement-related tools like 'binance_us_custodial_settlement' (which likely creates settlements) and 'binance_us_cust_settlement_history' (which might be for non-custodial accounts). However, it doesn't explicitly differentiate from all siblings, such as other history tools like 'binance_us_custodial_wallet_transfer_history'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for retrieving settlement history between custodial accounts. The warning '⚠️ REQUIRES CUSTODIAL SOLUTION API KEY' indicates a prerequisite. It doesn't explicitly state when not to use it or name alternatives, but the context (custodial settlements) implies it's not for non-custodial operations, which are covered by other tools like 'binance_us_cust_settlement_history'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a read operation ('Get') and describes the return content, but doesn't mention authentication requirements, rate limits, or potential errors. For a financial API tool with no annotation coverage, this leaves significant behavioral gaps regarding security and operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste. The first sentence states the purpose and scope, while the second elaborates on return details. Every word contributes to understanding the tool's function without redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple single-parameter input schema, the description provides adequate basic information about what the tool returns. However, for a financial account tool, it lacks details about authentication requirements, error handling, or data freshness that would be helpful for an AI agent. The description is complete enough for basic usage but has notable gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'recvWindow', which is fully documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 where the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('current account information') with specific details about what's included ('balances and permissions', 'all asset balances (free and locked), account permissions, and trading status'). It distinguishes itself from sibling tools like 'binance_us_cust_balance' or 'binance_us_subaccount_assets' by focusing on comprehensive account-level data rather than specific subsets or subaccount information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving account-level information but doesn't explicitly state when to use this tool versus alternatives like 'binance_us_cust_balance' (custodial balance) or 'binance_us_subaccount_assets' (subaccount assets). It provides context about what data is returned but lacks explicit guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what data is retrieved without disclosing behavioral traits. It doesn't mention whether this is a read-only operation, rate limits, authentication requirements, response format, or potential side effects. For a financial API tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence establishes core purpose, the second adds crucial filtering context. No wasted words, well-structured, and front-loaded with the main functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 100% schema coverage but no output schema and no annotations, the description is adequate but incomplete. It covers what data is retrieved and filtering options, but lacks information about response format, error conditions, or authentication requirements that would be helpful given the financial API context and numerous sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds marginal value by mentioning filtering capabilities that align with the parameters, but doesn't provide additional semantic context beyond what's already in the parameter descriptions. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get current exchange trading rules and trading pair information') and resource ('from Binance.US'), distinguishing it from siblings like account info or order tools. It precisely identifies what data is retrieved without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by mentioning filtering capabilities ('Can filter by specific symbol(s) or permissions'), which helps understand when to apply parameters. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among the many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It effectively discloses key behavioral traits: it's a read operation (implied by 'Get'), returns specific data structure (bids and asks with quantities), and importantly includes rate limit information (weight variations based on limit parameter). This covers critical operational constraints that annotations would normally provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose and critical operational constraints. The first sentence covers what the tool does, the second provides essential rate limit information. No wasted words, though it could be slightly more structured by separating purpose from constraints more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only market data tool with 2 parameters and no output schema, the description is reasonably complete. It covers purpose, return data structure, and rate limits. The main gap is lack of output format details (structure of returned bids/asks) and no comparison to alternative market data tools, but overall provides sufficient context for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing good documentation for both parameters. The description adds marginal value by mentioning the weight variations tied to the limit parameter, but doesn't provide additional semantic context beyond what's already in the schema descriptions. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get order book depth'), resource ('for a trading pair on Binance.US'), and output ('Returns price levels with quantities'). It distinguishes from siblings like ticker_24hr or ticker_price by focusing on order book depth rather than aggregated data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like ticker_book or recent_trades. The description mentions weight variations but doesn't provide context on when this tool is appropriate compared to other market data tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the API key requirement (important auth context) and lists response fields, which helps understand what to expect. However, it doesn't mention potential side effects, rate limits, error conditions, or whether this is a synchronous/asynchronous operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement up front, important warning, usage context, and response format. Every sentence serves a purpose. It could be slightly more concise by combining some of the response field explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial transfer tool with no annotations and no output schema, the description provides reasonable coverage of purpose, usage, and response format. However, it lacks important contextual details like error handling, confirmation requirements, settlement time, or whether this is an irreversible operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 4 parameters. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Transfer assets'), source ('from Binance.US exchange wallet'), and destination ('to custodial sub-account'). It distinguishes itself from sibling tools like 'binance_us_custodial_wallet_transfer' by specifying the direction of transfer (exchange to custodial).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to move assets from your Binance.US exchange wallet to your custodial sub-account for trading') and mentions the API key requirement. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 key behavioral traits: the API key requirement (auth needs), the response structure (data array and total), and details of transfer records (fields like transferId, status, timestamps). It doesn't mention rate limits, pagination behavior beyond parameters, or error handling, but covers essential operational context, earning a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: it starts with the core purpose, includes a critical warning, then lists response details. Every sentence adds value (e.g., the warning is essential, the response breakdown aids understanding). It's appropriately sized with zero waste, meeting the criteria for a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no annotations, no output schema), the description is fairly complete. It covers purpose, auth requirement, and response format, which helps the agent understand what to expect. However, it lacks details on error cases, pagination behavior beyond parameters, or how to interpret statuses, leaving minor gaps. With no output schema, it compensates well but not perfectly, justifying a 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 8 parameters. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't explain 'rail' or filtering logic further). According to the rules, with high schema coverage, the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get history of transfers from Binance.US exchange wallet to custodial sub-account.' It specifies the action ('Get history'), resource ('transfers'), and direction ('from exchange wallet to custodial sub-account'). However, it doesn't explicitly differentiate from sibling tools like 'binance_us_custodial_wallet_transfer_history' or 'binance_us_cust_transfer_history', which appear similar, so it doesn't reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context with the warning '⚠️ REQUIRES CUSTODIAL SOLUTION API KEY', indicating a prerequisite. However, it doesn't specify when to use this tool versus alternatives (e.g., compared to other transfer history tools in the sibling list) or any exclusions. The guidance is implied but not explicit, fitting a score of 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly indicates this is a read operation ('Query,' 'retrieves'), which is appropriate. It adds useful context about what OCBS is and the response structure, but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or whether it's paginated (though parameters suggest pagination).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with the core purpose, provides context about OCBS, and details the response format in a clear bulleted list. Every sentence adds value without redundancy, and it's front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description is fairly complete. It explains what the tool does, provides domain context about OCBS, and details the response structure. However, it lacks information about authentication, error handling, or pagination behavior, which would be helpful for a financial API tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 5 parameters. The description doesn't add any parameter-specific information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Query all OCBS (One-Click-Buy-Sell) fiat orders on Binance.US' with specific verb ('Query') and resource ('OCBS fiat orders'). It distinguishes from siblings by specifying OCBS fiat orders, which is a specific subset of orders not covered by generic order tools like 'binance_us_all_orders' or 'binance_us_otc_all_orders'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context by explaining OCBS allows 'direct fiat-to-crypto conversions' and retrieves 'OCBS order history for fiat transactions.' However, it doesn't explicitly state when to use this tool versus alternatives like 'binance_us_all_orders' or 'binance_us_otc_all_orders,' nor does it mention any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the key behavioral trait of being a non-executing validation tool, which is crucial. However, it lacks other important behavioral details like authentication requirements, rate limits, error responses, or whether it simulates market conditions. For a financial API tool with 14 parameters, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence establishes the core purpose, and the second clarifies the validation scope. No wasted words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex trading tool with 14 parameters, no annotations, and no output schema, the description is incomplete. While it correctly identifies the tool as non-executing, it doesn't address authentication needs, rate limits, error handling, or what the validation response contains. The agent would need to guess about these critical operational aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so each parameter is well-documented in the schema itself. The description doesn't add any parameter-specific semantics beyond what's in the schema, but with complete schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Test a new order'), resource ('on Binance.US'), and key differentiator ('without actually placing it'). It explicitly distinguishes this from actual order placement tools like 'binance_us_new_order' by emphasizing validation without execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Test a new order... without actually placing it' indicates this should be used for validation before executing trades. It implicitly contrasts with sibling tools like 'binance_us_new_order' for actual execution, though it doesn't explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 effectively communicates the destructive nature ('Use with caution - this will cancel ALL open orders'), which is critical for a mutation tool. However, it lacks details about authentication requirements, rate limits, error conditions, or what the response looks like (no output schema), leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and front-loaded: two sentences with zero waste. The first sentence states the core purpose, and the second adds crucial cautionary context. Every word earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high-stakes nature (destructive operation with no annotations and no output schema), the description is adequate but not fully complete. It covers the core action and warning, but lacks details on authentication, error handling, or response format. For a tool that cancels all orders, more contextual guidance would be beneficial, though the cautionary note partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds minimal value by reinforcing that 'symbol' is required and that all orders for this symbol will be cancelled, but doesn't provide additional syntax, format details, or context beyond what the schema specifies. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Cancel all active orders'), target resource ('on a symbol on Binance.US'), and scope ('This includes OCO orders'). It distinguishes itself from siblings like 'binance_us_cancel_order' (single order) and 'binance_us_cancel_oco' (specific OCO orders) by emphasizing the comprehensive 'ALL' nature of the cancellation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('cancel ALL open orders for the specified symbol') and includes a cautionary note about its broad impact. However, it doesn't explicitly state when NOT to use it or name specific alternatives (e.g., 'binance_us_cancel_order' for selective cancellation), which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does well by specifying the authentication requirement ('REQUIRES CUSTODIAL SOLUTION API KEY') and describing the return format ('Returns transfer history with status, amounts, and timestamps'). However, it doesn't mention important behavioral aspects like whether this is a read-only operation (implied by 'Get history' but not explicit), pagination behavior (though the schema hints at it), rate limits, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. The first sentence states the core purpose, the second provides critical authentication information with appropriate warning emoji, and the third describes the return format. Every sentence earns its place with no wasted words, and the most important information (what the tool does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no annotations, and no output schema, the description provides adequate but incomplete context. It covers the purpose, authentication requirement, and return format basics, but doesn't address the tool's behavioral profile (read-only vs. mutating, side effects), error handling, or provide guidance on parameter combinations. The 100% schema coverage helps, but more behavioral context would be beneficial given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions 'ExpressTrade and Undo transfers' which relates to the 'expressTradeTransfer' parameter, but doesn't provide additional context about parameter usage or relationships. This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get history of transfers from custodial partner, including ExpressTrade and Undo transfers.' It specifies the verb ('Get history'), resource ('transfers from custodial partner'), and scope ('including ExpressTrade and Undo transfers'), distinguishing it from sibling tools like 'binance_us_custodial_custodian_transfer' (which likely performs transfers rather than retrieving history).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for retrieving transfer history from custodial partners. It explicitly mentions '⚠️ REQUIRES CUSTODIAL SOLUTION API KEY' as a prerequisite. However, it doesn't explicitly state when not to use it or name specific alternatives among the many sibling tools (e.g., 'binance_us_custodial_wallet_transfer_history' might be a related alternative).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 indicates a read-only operation ('Get'), but does not disclose behavioral traits like rate limits, authentication needs, or error handling. The description is basic but not misleading, leaving gaps in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and efficiently communicates the essential information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool with no annotations and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on output format, error cases, or integration context, which could enhance completeness for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no additional parameter information is needed. The description does not add parameter details, but this is acceptable as the schema fully covers the absence of parameters, aligning with the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('current server time from Binance.US exchange'), making the purpose immediately understandable. It distinguishes itself from sibling tools by focusing solely on retrieving server time, unlike others that handle trades, orders, or account information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining server time, which is straightforward, but it does not explicitly state when to use this tool versus alternatives or any prerequisites. Given the tool's simple function, the implied context is adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 effectively describes what the tool returns (history of rewards with specific fields) and clarifies the default behavior when no asset is specified. However, it doesn't mention important behavioral aspects like whether this requires authentication, rate limits, pagination behavior beyond the parameters, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and front-loaded with the core purpose in the first sentence. Every subsequent sentence adds valuable information about the response format, record structure, and default behavior without any wasted words. The bulleted lists enhance readability while maintaining efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description provides adequate coverage of what the tool does and returns. However, it lacks important contextual information about authentication requirements, rate limits, error handling, and the relationship between pagination parameters that would be necessary for complete understanding by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already fully documents all 5 parameters. The description adds minimal value beyond the schema by mentioning the asset parameter's default behavior ('If no asset is specified, returns rewards for all staked assets'), but doesn't provide additional context about time formats, pagination strategy, or parameter interactions. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get staking rewards history') and resource ('for assets on Binance.US'), distinguishing it from sibling tools like 'binance_us_staking_balance' or 'binance_us_staking_history' which focus on different aspects of staking. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('Get staking rewards history') and includes an implicit alternative by noting 'If no asset is specified, returns rewards for all staked assets.' However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among the many sibling tools, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves current fee rates based on VIP level and notes that BNB discounts are excluded, adding useful context. However, it does not cover other behavioral aspects like authentication requirements, rate limits, or error handling, leaving gaps for a tool likely requiring user-specific data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of two sentences that directly state the tool's function and a key limitation. Every sentence adds value without redundancy, making it efficient and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving user-specific fee data) and no annotations or output schema, the description is somewhat complete but lacks details on authentication, response format, or error cases. It covers the core purpose and a limitation, but additional context would improve usability for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description does not add specific parameter details beyond what the schema provides, but it implicitly clarifies the context for the 'symbol' parameter by mentioning 'spot trading' and 'all symbols', offering slight semantic enhancement. With zero required parameters, this meets the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get') and resources ('maker & taker fee rates for spot trading'), and distinguishes it from siblings by focusing on fee rates based on VIP level. It explicitly mentions what is not included (BNB fee discount), which helps differentiate it from potential alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking fee rates in spot trading, but does not explicitly state when to use this tool versus alternatives (e.g., other fee-related tools or general account info). It mentions a specific limitation (BNB discount not factored), which provides some context, but lacks clear guidance on scenarios or prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 key behavioral traits: the tool is read-only (implied by 'Get'), uses a fixed 30-day rolling window, and updates daily at 0:00 UTC. However, it doesn't mention authentication requirements, rate limits, error conditions, or what the return format looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first states the core purpose and timeframe, the second adds crucial behavioral detail about calculation timing. Every word earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with no output schema and minimal parameters, the description covers the essential what and when. However, without annotations or output schema, it should ideally mention authentication needs, rate limits, or return format to be fully complete for API integration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its single parameter ('recvWindow'), so the baseline is 3. The description adds value by clarifying that volume is calculated on a rolling basis daily, which provides context beyond the parameter documentation, though it doesn't directly explain parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get total trade volume') with precise temporal scope ('for the past 30 days'), distinguishing it from siblings like 'binance_us_ticker_24hr' or 'binance_us_rolling_window' that provide different metrics or timeframes. It explicitly defines what resource is being retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying the 30-day rolling window and daily calculation timing, which helps differentiate from tools like 'binance_us_ticker_24hr' (24-hour window) or 'binance_us_rolling_window' (customizable window). However, it doesn't explicitly state when to use this tool versus alternatives or mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the requirement for a custodial API key (auth needs) and that it returns balance for placing new orders (read-only, non-destructive operation). It doesn't mention rate limits, error conditions, or response format details, but given the lack of annotations, it provides sufficient basic context for a read operation without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: it starts with the core purpose, includes a critical warning, and ends with the return value clarification. Every sentence earns its place, with no wasted words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a read operation with specific auth requirements), the description is complete enough: it covers purpose, prerequisites, and return value intent. No output schema is provided, but the description clarifies what the return represents. It lacks details on response format or error handling, but for a balance query tool, this is adequate, though not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('rail' and 'asset'). The description doesn't add any parameter-specific information beyond what the schema provides (e.g., no examples or usage tips for parameters). Since schema coverage is high, the baseline is 3, as the description doesn't compensate with extra semantic details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get available balance in the custodial sub-account for trading.' It specifies the verb ('Get'), resource ('available balance'), and scope ('custodial sub-account for trading'), which distinguishes it from general balance tools. However, it doesn't explicitly differentiate from sibling tools like 'binance_us_cust_balance' or 'binance_us_custodial_balance', which appear similar, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: it specifies that this is for 'trading' and includes a warning '⚠️ REQUIRES CUSTODIAL SOLUTION API KEY,' indicating prerequisites. It also clarifies the return value's purpose: 'Returns the balance available for placing new orders.' However, it doesn't explicitly state when to use this tool versus alternatives like 'binance_us_cust_balance' or other balance-related siblings, so it lacks explicit alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively communicates critical behavioral traits: it requires a specific API key ('REQUIRES CUSTODIAL SOLUTION API KEY'), initiates an external process ('This initiates a transfer request to your custody partner!'), and clarifies that execution is handled externally ('The actual transfer is executed by the custody partner.'). This covers authentication needs and process ownership, though it lacks details on rate limits, error handling, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with four sentences that are front-loaded with the core purpose. The warning emojis and capitalized text effectively highlight critical information without unnecessary verbosity. However, the third sentence ('This requests your custodial partner to transfer assets to your Binance.US account.') slightly repeats the first sentence, reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (financial transfer with external dependencies) and lack of annotations and output schema, the description is moderately complete. It covers the purpose, prerequisites, and behavioral context well, but it does not explain the return values, error conditions, or specific operational constraints like timing or limits. For a tool initiating external transfers, more detail on outcomes would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (rail, asset, amount, clientOrderId) with descriptions. The description does not add any parameter-specific semantics beyond what the schema provides, such as examples for 'rail' or constraints on 'amount'. The baseline score of 3 is appropriate since the schema handles the heavy lifting, but the description does not compensate with additional insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Request asset transfer') and resources involved ('from a custodial partner account to Binance.US custodial sub-account'). It distinguishes itself from sibling tools like 'binance_us_custodial_wallet_transfer' by specifying the source as a custodial partner rather than a wallet, and from 'binance_us_custodial_custodian_transfer_history' by focusing on initiating transfers rather than viewing history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Request asset transfer from a custodial partner account to Binance.US') and includes warnings about prerequisites ('REQUIRES CUSTODIAL SOLUTION API KEY') and implications ('This initiates a transfer request to your custody partner!'). However, it does not explicitly mention when NOT to use it or name specific alternatives among the many sibling tools, such as distinguishing from 'binance_us_custodial_wallet_transfer' for internal transfers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 describes the response format in detail (listing specific fields like asset, amount, type, etc.), which is helpful. However, it does not mention important behavioral aspects such as authentication requirements, rate limits, pagination behavior beyond the parameters, or whether this is a read-only operation (though implied by 'Get').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. It uses bullet points to clearly list response fields, and the final sentence efficiently handles the asset parameter default. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description is fairly complete. It explains the purpose, response format, and a key parameter default. However, it lacks details on authentication, rate limits, and error handling, which would be beneficial for a financial API tool with many sibling operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds value by explaining the default behavior for the asset parameter ('If no asset is specified, returns history for all assets'), but does not provide additional semantic context beyond what the schema descriptions offer for other parameters like startTime, endTime, page, or limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get', 'Returns') and resource ('staking transaction history for assets on Binance.US'). It distinguishes from siblings like 'binance_us_staking_balance' (which shows current balance) and 'binance_us_staking_rewards' (which shows rewards), focusing specifically on transaction history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to retrieve staking/unstaking transaction history) and includes a specific usage note about the asset parameter ('If no asset is specified, returns history for all assets'). However, it does not explicitly state when not to use it or name alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly states this is a cancellation operation (destructive action), specifies it cancels both legs of the OCO order, and describes the response format. It also mentions the API key requirement. However, it doesn't cover potential errors, rate limits, or confirmation of successful cancellation beyond the response details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with three clear sections: purpose statement, warning, and response details. It's appropriately sized with no redundant information. However, the warning emoji and formatting slightly reduce pure conciseness, though they add useful emphasis.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a cancellation tool with no annotations and no output schema, the description does a good job covering the essential context: what it does, that it's destructive, the API requirement, and response format. It could be more complete by mentioning potential side effects or error conditions, but it provides sufficient information for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 5 parameters. The description doesn't add any parameter-specific information beyond what's in the schema, such as explaining the relationship between orderListId and listClientOrderId, or when to use newClientOrderId. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Cancel an entire OCO order list') and identifies the resource (OCO orders). It distinguishes from sibling tools like 'binance_us_cancel_oco' (non-custodial version) and 'binance_us_cancel_order' (single order cancellation) by specifying it's for custodial OCO orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with the warning '⚠️ REQUIRES CUSTODIAL SOLUTION API KEY,' indicating this is specifically for custodial accounts. However, it doesn't explicitly state when to use this versus the non-custodial 'binance_us_cancel_oco' or other cancellation tools, though the custodial requirement implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses the API key requirement, explains that OCO counts as 2 orders against rate limits, and describes the response structure. It doesn't cover all potential behavioral aspects like error conditions or execution guarantees, but provides substantial operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (warning, OCO explanation, price restrictions, quantity note, rate limit impact, response details). It's appropriately sized for a complex tool, though some sentences could be more concise (e.g., the OCO explanation is slightly verbose). Most content earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex trading tool with 14 parameters, no annotations, and no output schema, the description provides good context: explains OCO mechanics, API requirements, rate limit impact, and response structure. It doesn't cover all edge cases or provide complete output documentation, but gives sufficient operational understanding for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 14 parameters thoroughly. The description adds some semantic context about quantity (both legs must have same quantity) and price restrictions for BUY/SELL, but doesn't provide significant additional parameter meaning beyond what's in the 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Place a new OCO order') and resource ('through the custodial solution'), distinguishing it from non-custodial OCO tools like 'binance_us_new_oco' and other custodial tools. It explains what an OCO order is, making the purpose explicit and differentiated from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with the warning '⚠️ REQUIRES CUSTODIAL SOLUTION API KEY', indicating when this tool is applicable (custodial context). However, it doesn't explicitly state when to use this versus alternatives like 'binance_us_cust_new_order' or non-custodial OCO tools, missing explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively communicates critical behavioral traits: the tool performs a reversal operation (implying mutation), requires specific authentication ('CUSTODIAL SOLUTION API KEY'), and has eligibility constraints ('Only certain transfers can be undone'). It also hints at potential limitations by advising to 'check with your custodial partner'. However, it lacks details on error conditions, response format, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured, with three sentences that each serve a distinct purpose: a clear purpose statement, critical warnings, and a reinforcing explanation. There is no redundant or unnecessary information, and the use of warning symbols (⚠️) effectively highlights important prerequisites.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with authentication and eligibility constraints), no annotations, and no output schema, the description is moderately complete. It covers purpose, prerequisites, and constraints but lacks details on the response format, error handling, or specific behavioral outcomes. This leaves gaps for an AI agent to fully understand the tool's execution context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('rail' and 'originTransferId') well-documented in the schema. The description adds minimal value beyond the schema, only mentioning 'transfer ID' which aligns with 'originTransferId'. It does not provide additional context, examples, or clarification for the parameters, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('undo', 'reverses') and resource ('previous transfer from your custodial partner', 'previous custodian transfer'), with explicit mention of the transfer ID. It distinguishes from sibling tools like 'binance_us_custodial_custodian_transfer' (which performs transfers) and 'binance_us_custodial_wallet_transfer' (which handles wallet transfers), making the purpose distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('undo a previous transfer', 'reverses a previous custodian transfer') and includes important prerequisites ('REQUIRES CUSTODIAL SOLUTION API KEY', 'Only certain transfers can be undone - check with your custodial partner'). However, it does not explicitly name alternative tools or specify when not to use it, such as distinguishing from 'binance_us_cust_undo_transfer' (which might handle non-custodial transfers).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively communicates critical behavioral traits: the tool moves funds (destructive operation), requires specific API key permissions, and includes a warning to verify details. It also explains the purpose of the transfer (enabling trading/settlement). The main gap is lack of information about rate limits, error conditions, or confirmation mechanisms.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences. The warning emojis and capital letters effectively front-load critical information. The second sentence could be slightly more concise, but overall the structure is efficient with zero wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a fund transfer tool with no annotations and no output schema, the description provides good contextual completeness. It covers the destructive nature, authentication requirements, and purpose of the operation. The main gap is the lack of information about what the tool returns (success/failure indicators, transaction IDs, etc.), which would be helpful given there's no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. This meets 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Transfer assets') and resources involved ('from your Binance.US exchange wallet to your custodial sub-account'). It distinguishes this tool from sibling tools like 'binance_us_custodial_balance' (which reads balances) and 'binance_us_custodial_custodian_transfer' (which transfers to custodial partners rather than sub-accounts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (transferring assets to custodial sub-accounts for trading/settlement) and includes important prerequisites (requires custodial solution API key). However, it doesn't explicitly state when NOT to use it or name specific alternative tools for different transfer scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively discloses key behavioral traits: it's a read-only operation (implied by 'Get a list'), describes the response format in detail (listing fields like fromCoin/toCoin and min/max amounts), and explains the OTC context and benefits (minimizing market impact). It lacks details on rate limits or authentication needs, but covers core behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by explanatory context, response details, and an example. Every sentence adds value, though the example could be more concise. No wasted text, but minor room for tightening.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (read-only list with filtering), no annotations, and no output schema, the description does a good job: it explains the OTC context, details the response structure, and provides an example. It could improve by mentioning authentication or rate limits, but it's largely complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (fromCoin, toCoin) well-described in the schema. The description adds minimal parameter semantics beyond the schema—it mentions filtering in the response explanation but doesn't clarify parameter usage or provide examples. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a list of supported OTC (Over-The-Counter) trading pairs on Binance.US.' It specifies the verb ('Get'), resource ('list of supported OTC trading pairs'), and distinguishes it from siblings like 'binance_us_exchange_info' (regular exchange info) or 'binance_us_otc_place_order' (placing OTC orders).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for OTC trading to minimize market impact, as explained in 'OTC trading allows large block trades... minimizing market impact.' However, it does not explicitly state when not to use it or name alternatives among siblings (e.g., 'binance_us_exchange_info' for regular trading pairs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively explains key traits: the tool is for requesting quotes (not executing trades), quotes expire based on 'validTimestamp', and it requires quick use. This covers critical operational behavior, though it could add details like rate limits or authentication needs for completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, important warnings highlighted, and organized sections for parameters and response. It avoids redundancy, but the parameter list slightly repeats schema information, and the response details could be more concise given the lack of an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no annotations, no output schema), the description is mostly complete. It explains the tool's purpose, usage context, behavioral traits, and response format. However, it lacks details on error handling or authentication requirements, which would enhance completeness for a financial API tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters fully. The description lists parameters and provides examples (e.g., 'BTC, SHIB'), but adds minimal semantic value beyond the schema. This meets the baseline for high schema coverage, where the description doesn't need to compensate heavily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Request a quote for an OTC trade') and resource ('on Binance.US'), with the first sentence providing a concise overview. It distinguishes this tool from siblings like 'binance_us_otc_place_order' by focusing on quote retrieval rather than order execution, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool—to get a price quote before placing an OTC trade—and warns about quote expiration, which is crucial timing guidance. However, it does not explicitly mention when not to use it or name alternatives like 'binance_us_otc_place_order' for actual trading, leaving some room for improvement in sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it discloses that unstaking takes time, stops rewards, and may incur penalties—all critical behavioral traits beyond basic functionality. It doesn't mention authentication needs or rate limits, but covers key operational implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose statement, important warnings in a bulleted section, and parameter/response details. Every sentence adds value, though the parameter listing is somewhat redundant given schema coverage. Slightly verbose but front-loaded with critical info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description does well: it explains the action, key behavioral constraints, parameters, and response format. Could mention authentication or error cases, but covers essentials given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description lists parameters but adds minimal extra meaning (e.g., 'e.g., BNB, ETH' is redundant with schema). Baseline 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('unstake') and resource ('a previously staked asset on Binance.US'), distinguishing it from sibling tools like 'binance_us_staking_stake' (stake) and 'binance_us_staking_balance' (check balance). It's specific about the action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to unstake assets) and implicitly contrasts with staking tools, but doesn't explicitly name alternatives or state when not to use it. The ⚠️ section offers important usage considerations but not explicit 'when-not' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that user data streams require a listen key, adding useful context about authentication needs. However, it lacks details on rate limits, response format, or potential errors, leaving behavioral gaps for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a bulleted list of return details. Every sentence earns its place by providing essential information without waste, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description does well by outlining return details. However, it lacks information on response structure, error handling, or operational constraints, which are important for a tool in a complex API environment with many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on what the tool returns rather than inputs, earning a high score as it adds value without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get information') and resource ('available WebSocket streams on Binance.US'), distinguishing it from siblings that focus on account data, trading, or other API endpoints. It explicitly mentions the types of streams covered, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by listing what information is returned (market data streams, user data streams, connection URLs and limits), which implicitly suggests when to use it—for WebSocket setup or configuration. However, it does not explicitly state when not to use it or name alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively warns about the critical action ('transfers USD OUT of your account!') and identifies the payment method (BITGO). However, it lacks details about permissions, rate limits, confirmation requirements, or what happens after submission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) with zero wasted words. It front-loads the core purpose and follows with a critical warning. Every sentence earns its place by providing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial transaction tool with no annotations and no output schema, the description provides adequate basic information about the action and warning. However, it lacks details about authentication requirements, transaction limits, processing time, error conditions, or what the tool returns upon success/failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions, maintaining the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Submit a USD withdrawal request') and resource ('via BITGO'), distinguishing it from sibling tools like 'binance_us_withdraw_crypto' by specifying fiat withdrawal. It uses a specific verb and identifies the exact resource being manipulated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (USD withdrawal via BITGO) and implicitly distinguishes it from crypto withdrawals. However, it doesn't explicitly mention when NOT to use it or name specific alternatives like 'binance_us_withdraw_crypto' for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively describes what the tool returns (detailed alert records with specific fields), its specialized use case (credit line accounts with institutional agreements), and the nature of the data (historical alerts for risk analysis). It doesn't mention rate limits, authentication needs, or pagination behavior, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficiently organized: purpose statement, critical warning, alert type definitions, record structure details, and use cases. Every sentence adds value with no redundancy. The warning is appropriately front-loaded with an emoji for emphasis.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only historical data tool with no output schema, the description provides excellent context: it explains what data is returned, the record structure, use cases, and critical prerequisites. The main gap is the lack of information about response format (e.g., pagination, error handling), but given the tool's relatively straightforward nature and comprehensive parameter documentation, this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so parameters are well-documented in the structured schema. The description doesn't add parameter-specific information beyond what's in the schema, but it does provide context about alert types (MARGIN_CALL vs LIQUIDATION_CALL) that helps interpret the 'alertType' parameter's enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get margin call and liquidation alert history for credit line account.' It specifies the exact resource (alert history) and distinguishes it from siblings like 'binance_us_cl_liquidation_history' by focusing on alerts rather than just liquidations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use this tool ('Review past risk events', 'Understand account risk patterns', 'Audit margin call history') and includes a critical prerequisite warning ('⚠️ REQUIRES INSTITUTIONAL CREDIT LINE AGREEMENT'). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and effectively discloses key behavioral traits: it describes the destructive action ('invalidating the listen key'), the consequence ('WebSocket connection will be terminated'), and authentication requirements ('requires API key but does NOT require signature'). This covers mutation, effects, and auth needs clearly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: purpose, usage timing, and consequences/requirements. Each sentence adds essential information without redundancy, making it front-loaded and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is largely complete: it explains purpose, usage, effects, and auth. However, it lacks details on error conditions or response format, which could be helpful for a mutation tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'listenKey' fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or validation rules, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Close a User Data Stream by invalidating the listen key') and resource ('listen key'), distinguishing it from siblings like 'binance_us_create_listen_key' and 'binance_us_keepalive_listen_key' which handle creation and maintenance of listen keys respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use this tool ('Use this when you're done receiving real-time updates'), but does not mention when NOT to use it or name specific alternatives. It implies usage relative to the WebSocket lifecycle without detailing prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses behavioral traits: it's a read operation (implied by 'Get'), includes a critical prerequisite (institutional agreement), describes the return format (listing transfer record fields like transferId, status, etc.), and hints at filtering capabilities (via transferType and asset). It does not mention rate limits, pagination, or error handling, but covers key aspects for a history tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: it starts with the core purpose, includes a critical warning, details transfer types and record fields, and ends with use cases. Every sentence adds value without redundancy, making it efficient and easy to scan for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a financial history tool with 6 parameters) and no annotations or output schema, the description is largely complete. It covers purpose, prerequisites, data format, and usage. However, it lacks details on output structure (e.g., pagination, error responses) and does not mention sibling tools for context, which could help in tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds minimal value beyond the schema: it explains the semantics of 'transferType' (TRANSFER_IN/TRANSFER_OUT) and 'asset', but these are already covered in the schema's enum and description. No additional parameter insights are provided, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('transfer history for credit line account'), making the purpose specific. It distinguishes from siblings like 'binance_us_cl_account' (which likely gets account info) and 'binance_us_cl_transfer' (which likely performs transfers), by focusing on historical data retrieval rather than current state or actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with the warning 'REQUIRES INSTITUTIONAL CREDIT LINE AGREEMENT', indicating prerequisites. It lists specific use cases ('Track collateral movements', 'Audit deposit/withdrawal history', 'Reconcile account activity'), which helps guide when to use it. However, it does not explicitly state when NOT to use it or name alternatives among siblings, such as 'binance_us_cust_transfer_history' for non-credit-line accounts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it discloses authentication requirements ('REQUIRES CUSTODIAL SOLUTION API KEY'), specifies the operation's effect (cancels active orders), and describes the response format (includes canceled order details with status: CANCELED). It lacks details on rate limits or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three sentences: purpose statement, authentication warning, parameter requirement, and response details. Each sentence adds essential information with zero waste, and critical warnings are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is fairly complete: it covers purpose, authentication, key parameters, and response behavior. It could improve by addressing potential side effects or error cases, but given the schema's full parameter coverage, it provides adequate context for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds minimal value beyond the schema by noting the either/or requirement for orderId/origClientOrderId, but does not explain parameter interactions or provide additional context like examples for 'rail' values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Cancel') and resource ('an active custodial trade order'), distinguishing it from non-custodial siblings like 'binance_us_cancel_order' by specifying 'custodial' in both name and description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use this tool (requires custodial API key) and clarifies parameter requirements ('Either orderId or origClientOrderId must be provided'), but does not explicitly mention when not to use it or name alternatives like 'binance_us_cancel_order' for non-custodial cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds significant behavioral context: it discloses the requirement for a custodial solution API key, warns to use with caution (implying destructive action), specifies inclusion of OCO orders, and describes the response format. However, it lacks details on rate limits, error conditions, or permission levels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by critical warnings and response details in three concise sentences. Every sentence earns its place: the first states the action, the second specifies prerequisites and caution, and the third clarifies scope and output. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with API key requirement) and lack of annotations/output schema, the description is mostly complete: it covers purpose, prerequisites, caution, scope (OCO orders), and response format. However, it misses details like error handling or confirmation prompts, leaving minor gaps for a high-stakes tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('rail' and 'symbol') with descriptions. The description adds no additional parameter semantics beyond implying the tool operates on a 'specific trading pair', which is redundant with the schema. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Cancel') and resource ('all active custodial orders for a specific trading pair'), making the purpose specific and unambiguous. It distinguishes from sibling tools like 'binance_us_cancel_order' (single order) and 'binance_us_cancel_all_open_orders' (non-custodial orders) by specifying custodial scope and inclusion of OCO orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use this tool: for canceling custodial orders with a specific trading pair, including OCO orders. It warns 'Use with caution' but does not explicitly state when NOT to use it or name alternatives (e.g., non-custodial cancel tools). The API key requirement is noted, but no comparison to siblings is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 key behavioral traits: the requirement for a custodial API key (auth needs) and lists the response fields, giving insight into what data is returned. It does not mention rate limits, error handling, or whether it's read-only, but covers essential operational context adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a critical warning and a concise list of response fields. Every sentence earns its place, with no redundant information, making it efficient and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (custodial order retrieval with specific auth needs), no annotations, and no output schema, the description does a good job by stating the purpose, auth requirement, and response fields. It could improve by mentioning error cases or rate limits, but it provides sufficient context for basic usage without being incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all parameters (rail, symbol, orderId) well-documented in the input schema. The description does not add any parameter-specific details beyond what the schema provides, such as examples or usage notes, so it meets the baseline for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'details of a specific custodial trade order,' specifying it's for a particular order. It distinguishes from siblings like 'binance_us_get_order' (non-custodial) and 'binance_us_cust_open_orders' (multiple orders), making the purpose specific and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a warning '⚠️ REQUIRES CUSTODIAL SOLUTION API KEY,' providing clear context for when to use this tool (with custodial API access). However, it does not explicitly mention when not to use it or name alternatives like the non-custodial 'binance_us_get_order,' which would be helpful for full differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively describes the tool's behavior: it's a read operation (implied by 'Get'), discloses authentication requirements (custodial API key needed), and details the return structure including specific balance fields and their meanings. It lacks information on rate limits, error conditions, or pagination, but provides substantial context beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It front-loads the core purpose, follows with a critical warning, then details the return values. Every sentence adds value: the first states what it does, the second provides essential prerequisites, and the remaining sentences explain the output structure clearly without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving balance data from two sources), no annotations, and no output schema, the description does a good job of being complete. It explains the purpose, prerequisites, and detailed return structure. It could improve by mentioning potential errors or rate limits, but covers the essential context well for a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting the single required 'rail' parameter. The description does not add any parameter-specific information beyond what the schema provides. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get balance information') and resources ('Binance.US exchange wallet and custodial sub-account'). It distinguishes from sibling tools like 'binance_us_cust_balance' by specifying it returns both exchange wallet and custodial sub-account balances, not just custodial.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use this tool (to get balance information for both exchange wallet and custodial sub-account) and includes a critical prerequisite warning about requiring a custodial solution API key. However, it does not explicitly state when not to use it or name specific alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively communicates critical behavioral traits: the tool performs a withdrawal/settlement action (implying mutation), requires specific API credentials, and involves sending funds externally ('⚠️ This sends funds to your custodial partner!'). It also clarifies the direction of transfer. However, it doesn't mention potential side effects like irreversible transactions, rate limits, or confirmation times.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured, with only three sentences plus warning symbols. The first sentence states the purpose, warnings highlight critical requirements and risks, and the final sentence reinforces the action. Every sentence earns its place by adding essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (financial settlement with external transfer), lack of annotations, and no output schema, the description does a good job covering the core purpose, prerequisites, and risks. However, it lacks details on return values (e.g., confirmation IDs, status), error conditions, or operational constraints like minimum amounts or supported rails, which would be helpful for a mutation tool of this nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, providing complete parameter documentation. The description adds no specific parameter semantics beyond what's in the schema (e.g., it doesn't explain 'rail' values or 'asset' formats). Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't need to compensate for schema gaps but also doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('settles (withdraws) assets') and resources involved ('from your Binance.US custodial sub-account to your custody partner's vault'), using precise terminology. It effectively distinguishes this tool from sibling tools like 'binance_us_custodial_wallet_transfer' or 'binance_us_custodial_custodian_transfer' by focusing on settlement to a custodial partner rather than internal transfers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (settling assets to a custodial partner) and includes critical prerequisites ('⚠️ REQUIRES CUSTODIAL SOLUTION API KEY'). However, it doesn't explicitly state when NOT to use it or name specific alternative tools for different scenarios, such as using 'binance_us_custodial_wallet_transfer' for internal wallet transfers instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively describes the tool's behavior by specifying the API key requirement (⚠️ REQUIRES CUSTODIAL SOLUTION API KEY) and detailing the return structure with two lists and their contents. This covers key operational aspects beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by important warnings and return details. Every sentence adds value: the first states the purpose, the second highlights requirements, and the subsequent lines explain the output structure efficiently without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description does a good job of covering essential context: it explains the purpose, requirements, and return format. However, it could be more complete by mentioning potential errors, rate limits, or authentication details beyond the API key note, given the complexity of custodial operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting the single required parameter 'rail' as a custodial partner identifier. The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 without compensating for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get list of assets') and resources ('supported for custodial transfers and settlements'). It distinguishes from sibling tools like 'binance_us_cust_supported_assets' by specifying the custodial context, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (for custodial transfers/settlements) and includes a warning about API key requirements. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools, such as 'binance_us_cust_supported_assets' for non-custodial contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 key behavioral traits: the requirement for a custodial API key (auth needs), the default behavior for missing 'symbol' parameter, and details about the response format (array of orders with specific fields). It does not mention rate limits or pagination, but covers essential operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a critical warning and key usage notes. Every sentence earns its place: the first states the action, the second highlights a prerequisite, and the last two explain parameter behavior and response details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description does well by covering auth requirements, parameter defaults, and response structure. However, it lacks details on error handling, rate limits, or pagination for the array response, which would be helpful for a tool with 6 parameters and historical data retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by clarifying the default behavior for 'symbol' when omitted, but does not provide additional syntax or format details beyond what the schema specifies. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('historical custodial trade orders'), making the purpose specific. It distinguishes from siblings like 'binance_us_cust_open_orders' (current orders) and 'binance_us_cust_trade_history' (trades vs. orders) by focusing on historical orders, though not explicitly named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with the warning about requiring a custodial API key and explains the default behavior when 'symbol' is omitted. However, it does not explicitly state when to use this tool versus alternatives like 'binance_us_cust_open_orders' or 'binance_us_cust_trade_history', missing explicit sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behavioral traits: it's a read operation ('Get'), requires specific authentication (custodial API key), and describes the response structure (records array, total count, record fields). It doesn't mention rate limits or pagination details, but covers essential behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: purpose first, then warning, then response details. Every sentence adds value—no waste. It's appropriately sized for a tool with detailed output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description compensates well by explaining authentication needs and response format. It covers purpose, usage context, and output semantics. Minor gaps include lack of error handling or pagination behavior, but it's largely complete for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no parameter-specific information beyond what's in the schema, but implies filtering by time (mentions 'past automatic settlements') which aligns with startTime/endTime. Baseline 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'historical settlement records for custodial solution.' It distinguishes from siblings like 'binance_us_custodial_settlement_history' by specifying it's for 'custodial solution' (implied distinct API), and from other custodial tools (e.g., balance or transfer tools) by focusing on settlement history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states '⚠️ REQUIRES CUSTODIAL SOLUTION API KEY,' providing clear context for when to use (with custodial API). It doesn't specify when not to use or name alternatives, but the context is sufficient given the specialized nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It effectively discloses key behavioral traits: it's a read-only operation ('Get'), requires specific authentication ('CUSTODIAL SOLUTION API KEY'), and describes the response structure including three specific fields. It doesn't mention rate limits, error conditions, or whether the data is real-time vs cached, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. It leads with the core purpose, immediately highlights the critical authentication requirement with warning emoji, then details what information is returned. Every sentence earns its place with no redundant information. The bulleted response format enhances readability without adding unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read operation with no output schema, the description provides excellent context. It covers purpose, authentication requirements, and response structure. The main gap is the lack of annotations, but the description compensates well by disclosing key behavioral information. It doesn't explain error handling or provide examples, but gives sufficient information for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single 'rail' parameter fully documented in the schema. The description doesn't add any parameter-specific information beyond what the schema already provides ('Custodial partner name (e.g., ANCHORAGE, BITGO). Must be uppercase.'). Baseline score of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Get') and resource ('current settlement settings for custodial solution'). It distinguishes from sibling tools like 'binance_us_cust_settlement_history' (which retrieves historical data) and 'binance_us_custodial_settlement' (which likely performs settlements). The description explicitly mentions what configuration and schedule information is retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool: for retrieving settlement settings specifically for custodial solutions. It explicitly states 'REQUIRES CUSTODIAL SOLUTION API KEY' as a prerequisite. However, it doesn't explicitly mention when NOT to use it or name specific alternative tools for non-custodial settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses that this is a read-only operation (implied by 'Get list'), specifies authentication requirements (custodial API key), and describes the response structure including transferEligible and settlementEligible categories. It doesn't mention rate limits or error conditions, but covers key behavioral aspects well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured: purpose statement first, critical warning prominently displayed, then response format details. Every sentence adds value with zero waste. The warning emoji draws appropriate attention to the authentication requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description provides excellent context: clear purpose, authentication requirements, and detailed response structure. It doesn't explain potential error cases or rate limits, but covers the essential information needed to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single 'rail' parameter. The description doesn't add any parameter-specific information beyond what's in the schema. This meets 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'list of assets supported for custodial solution transfers and settlements'. It specifically distinguishes this tool from siblings like 'binance_us_custodial_supported_assets' by focusing on eligibility for transfers and settlements rather than just listing supported assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states '⚠️ REQUIRES CUSTODIAL SOLUTION API KEY' which provides clear context about prerequisites. However, it doesn't specify when to use this tool versus alternatives like 'binance_us_custodial_supported_assets' or other asset-related tools, missing explicit sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it requires a specific API key (custodial solution), describes what gets returned (executed trades with detailed fields), and mentions the response format. However, it doesn't cover potential rate limits, pagination behavior, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core purpose first, followed by critical warning, then return details. Every sentence earns its place: first states what it does, second specifies requirements, third clarifies return type, fourth enumerates response fields. Zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no annotations and no output schema, the description provides good coverage of purpose, requirements, and return format. However, it could be more complete by mentioning potential limitations (e.g., date range constraints, maximum history depth) or error scenarios given the complexity of financial API tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions, maintaining the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get historical custodial trades'), the resource ('filled orders'), and distinguishes it from siblings by specifying it's for custodial trades only (unlike non-custodial trade tools like 'binance_us_my_trades' or 'binance_us_historical_trades'). The first sentence directly answers what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (for custodial trades with the warning about API key requirements) but doesn't explicitly state when not to use it or name specific alternatives among the many sibling tools. It implies usage for historical custodial trades but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively communicates critical behavioral traits: it is a write/mutation operation (implied by 'Transfer'), requires specific authentication ('CUSTODIAL SOLUTION API KEY'), and describes the response structure. However, it lacks details on error conditions, rate limits, or idempotency, which would be helpful for a financial transfer tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by essential warnings and usage context, then response details. Every sentence earns its place—no fluff or redundancy. It is appropriately sized for a tool with authentication requirements and a detailed response.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (financial transfer with authentication needs) and the absence of annotations and output schema, the description does a good job covering purpose, prerequisites, usage, and response format. However, it could be more complete by addressing potential errors, idempotency, or rate limits, which are important for such operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description does not add any parameter-specific semantics beyond what the schema provides (e.g., it doesn't explain 'rail' options or 'asset' constraints further). Baseline 3 is appropriate as the schema does the heavy lifting, but no extra value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Transfer assets') and resources involved ('from custodial partner account to Binance.US custodial sub-account'), distinguishing it from sibling tools like 'binance_us_cust_wallet_transfer' or 'binance_us_subaccount_transfer' which involve different transfer types. The purpose is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use this tool ('to move assets from your custodial partner... to your Binance.US custodial sub-account for trading') and mentions a prerequisite ('REQUIRES CUSTODIAL SOLUTION API KEY'). However, it does not explicitly state when NOT to use it or name specific alternative tools for different transfer scenarios, though the context implies differentiation from other transfer-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing important behavioral traits: the API key requirement, the types of transfers included (ExpressTrade, Custodian, Undo), and the response structure. It doesn't mention rate limits, authentication details beyond the API key, or error behaviors, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement upfront, followed by prerequisite warning, scope details, and response format. Every sentence adds value with zero waste, and information is well-organized for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only history tool with no annotations but 100% schema coverage, the description provides good completeness: clear purpose, prerequisites, scope, and response format. Without an output schema, the response details are valuable. It could benefit from mentioning pagination behavior or typical use cases, but covers the essentials well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 doesn't add parameter-specific information beyond what's already documented in the schema, though it implies filtering capabilities through the response field descriptions. No additional syntax or format details are provided for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get history of transfers') and resource ('from custodial partner to Binance.US custodial sub-account'), distinguishing it from sibling tools like 'binance_us_custodial_custodian_transfer_history' or 'binance_us_cust_wallet_transfer_history' by specifying the exact transfer source and destination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to retrieve transfer history from custodial partners) and includes a critical prerequisite warning ('REQUIRES CUSTODIAL SOLUTION API KEY'), but doesn't explicitly state when not to use it or name specific alternative tools for different transfer types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It effectively communicates critical behavioral traits: the requirement for a custodial solution API key (⚠️ warning), the fact that it reverses transfers, and what the response includes (transferId, asset, amount). This covers key operational aspects, though it could mention potential limitations like time windows or irreversible states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement upfront, followed by a critical warning, usage context, and response details. Every sentence adds value without redundancy, and the bulleted response format enhances readability while maintaining brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter mutation tool with no annotations and no output schema, the description does well by covering purpose, prerequisites (API key), usage context, and response structure. It provides enough information for an agent to understand when and how to use it, though it could be more complete by addressing potential errors or confirming the mutation's effect (e.g., whether the original transfer is deleted or marked).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (rail and originTransferId). The description doesn't add any parameter-specific information beyond what's in the schema, such as examples of valid rails or format of transfer IDs. This meets 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Undo a previous transfer') and resource ('from your custodial partner'), distinguishing it from sibling tools like 'binance_us_cust_transfer' or 'binance_us_custodial_custodian_transfer' which likely handle forward transfers. It avoids tautology by explaining the reversal function rather than just restating the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to reverse a custodian transfer that hasn't been fully processed'), which helps differentiate it from other transfer-related tools. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the many sibling tools, keeping it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and adds valuable behavioral context: it discloses rate limit implications (weight 40 vs 3) for unfiltered queries, which is critical for API usage. However, it lacks details on authentication needs, pagination, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first states the purpose and filtering capability, the second warns about rate limits. It is front-loaded and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is fairly complete for a read operation, covering purpose, filtering, and rate limits. However, it could improve by mentioning authentication requirements or response format, though the lack of output schema is not its fault.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds marginal value by explaining the symbol filter's purpose and rate limit impact, but does not provide additional syntax or format details beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'all open orders on Binance.US', specifying it can be filtered by symbol. It distinguishes from siblings like 'binance_us_all_orders' (historical) and 'binance_us_cust_open_orders' (custodial) by focusing on current open orders, though not explicitly named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use symbol filtering (to reduce rate limit impact) but does not explicitly mention when not to use this tool versus alternatives like 'binance_us_cust_open_orders' for custodial orders or 'binance_us_all_orders' for historical data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it's a read operation (implied by 'Get'), it returns specific status values (SUCCESS, PROCESS, etc.), and details the response structure including 8 specific fields. However, it doesn't mention authentication requirements, rate limits, or error conditions that would be helpful for a financial API tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and front-loaded: first sentence states the core purpose, second provides usage context, then bullet points detail the response format. Every sentence earns its place with zero wasted words. The bulleted list efficiently communicates complex return data without verbose explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description provides excellent context: clear purpose, usage guidance, and detailed response structure. The main gap is lack of authentication/rate limit information which would be valuable for a financial API. However, given the tool's simplicity and the comprehensive response documentation, it's mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'orderId' well-documented in the schema. The description doesn't add any parameter information beyond what the schema provides (both mention it's an OTC order ID), so it meets the baseline of 3 when schema does the heavy lifting. No additional syntax or format details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Get detailed information') and resource ('specific OTC trade order'), distinguishing it from siblings like 'binance_us_otc_all_orders' (which lists orders) and 'binance_us_otc_place_order' (which creates orders). It explicitly identifies the scope as OTC trades, which is distinct from regular exchange tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to check the status and details of a previously placed OTC order'), but doesn't explicitly mention when NOT to use it or name specific alternatives. It implies usage for existing orders rather than new ones, but lacks explicit exclusions or comparison with similar tools like 'binance_us_get_order' (non-OTC).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively describes the tool's behavior by detailing the response structure, including specific fields like APR, APY, and staking limits, and explains the conditional logic for the optional parameter. It does not mention rate limits, authentication needs, or error handling, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose, followed by response details and parameter behavior. Each sentence adds essential information without redundancy, such as listing response fields and explaining the optional parameter's impact, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (read-only operation with one optional parameter) and no output schema or annotations, the description is largely complete. It covers the purpose, response structure, and parameter semantics adequately. However, it lacks details on potential errors, rate limits, or authentication requirements, which could enhance completeness for a financial API tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'stakingAsset' well-documented in the schema. The description adds minimal value beyond the schema by reiterating the optional nature and effect ('If no asset is specified, returns information for all staking assets'), but does not provide additional syntax or format details. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get staking information') and resource ('supported assets on Binance.US'), distinguishing it from sibling tools like 'binance_us_staking_balance' or 'binance_us_staking_history' which focus on different aspects of staking. It explicitly defines the scope as returning details about staking options, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by explaining the behavior when no asset is specified ('returns information for all staking assets'), which helps the agent decide when to use the optional parameter. However, it does not explicitly state when to use this tool versus alternatives like 'binance_us_staking_balance' or other staking-related siblings, missing explicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a read operation ('Get') and details the response structure, which is helpful. However, it does not mention authentication requirements, rate limits, or error handling, which are important for a financial API tool. The description adds value but lacks comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by response details and parameter guidance. Every sentence adds value: the first states the action, the second clarifies the return, the third lists response fields, and the fourth explains parameter behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (read operation with one optional parameter) and no output schema, the description is mostly complete: it explains the purpose, response structure, and parameter semantics. However, it lacks details on authentication, rate limits, or error handling, which are important for API tools. Without annotations, these gaps prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds semantic context by explaining the effect of the optional 'asset' parameter ('If no asset is specified, returns balances for all staked assets'), which clarifies usage beyond the schema's technical description. This elevates the score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get current staking balance') and resource ('for assets on Binance.US'), distinguishing it from sibling tools like 'binance_us_staking_asset_info' or 'binance_us_staking_history' by focusing on current positions rather than informational or historical data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Get current staking balance') and includes usage guidance for the optional parameter ('If no asset is specified, returns balances for all staked assets'). However, it does not explicitly state when not to use it or name alternatives among siblings, such as 'binance_us_staking_asset_info' for asset details or 'binance_us_staking_history' for historical data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: it's a read-only check (implied by 'Check'), requires authentication ('Requires API key authentication'), and defines the return format (status codes 0 and 1). This covers essential aspects like operation type and auth needs, though it lacks details on rate limits or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and front-loaded: it states the core purpose in the first clause, adds critical status code details, and ends with authentication requirements. Every sentence earns its place with no wasted words, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is largely complete. It explains what the tool does, the return format, and authentication needs. However, without an output schema, it could benefit from clarifying the exact structure of the response (e.g., JSON format), though the status codes provide sufficient guidance for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the inputs. The description adds no parameter information, which is appropriate. Baseline is 4 for 0 parameters, as there's nothing to compensate for, and the description doesn't need to cover params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Check if Binance.US system is under maintenance') and resource ('Binance.US system'), distinguishing it from siblings that focus on trading, account management, or other operations. It provides precise status codes (0=normal, 1=maintenance), making the purpose unambiguous and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'Requires API key authentication,' suggesting it's for authenticated system status checks. However, it doesn't explicitly state when to use this tool versus alternatives like 'binance_us_ping' or 'binance_us_server_time' for system availability, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively communicates critical traits: it's a destructive action ('transfers funds OUT of your account'), includes a safety warning ('verify address carefully'), and specifies a permission requirement ('withdrawal permission on API key'). However, it does not mention potential side effects like fees, processing times, or irreversible nature, which could be important for a withdrawal tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and key warnings in just two sentences, with zero wasted words. Every sentence earns its place by conveying essential information (action, permission, risk warning) efficiently, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a crypto withdrawal tool with no annotations and no output schema, the description does a good job covering the basics: purpose, permissions, and risks. However, it lacks details on return values (e.g., confirmation ID, status) or error conditions, which would be helpful for an agent to handle responses. It's mostly complete but has minor gaps in output expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all 7 parameters thoroughly. The description does not add any additional meaning or context about the parameters beyond what the schema provides (e.g., it doesn't explain parameter interactions or provide examples). The baseline score of 3 is appropriate since the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Submit a crypto withdrawal request') and resource ('funds OUT of your account'), distinguishing it from sibling tools like binance_us_withdraw_fiat (for fiat) and binance_us_withdraw_history (for viewing history). It directly addresses what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (for crypto withdrawals) and includes a prerequisite ('Requires withdrawal permission on API key'), but it does not explicitly state when not to use it or name alternatives (e.g., using binance_us_withdraw_fiat for fiat withdrawals). The guidance is helpful but lacks explicit exclusions or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively describes the tool's behavior by listing the comprehensive response structure (LTV ratios, interest & fees, contract details, permissions, loan information, balances) and specifying institutional access requirements. However, it doesn't mention rate limits, authentication needs, or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Response includes, LTV Ratios, Interest & Fees, etc.) and uses bullet points for readability. It's appropriately sized for the complexity of the tool, though some sections could be slightly more concise (e.g., the bullet points are detailed but necessary).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (credit line information with multiple data categories) and no output schema, the description provides substantial context by detailing the response structure comprehensively. It covers key aspects like access restrictions, data categories, and specific fields. However, it lacks information on error handling or example responses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its single parameter 'recvWindow', so the schema already documents it fully. The description adds no parameter-specific information beyond what the schema provides, which is acceptable given the high schema coverage, resulting in the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb ('Get') and resource ('comprehensive credit line account information'), clearly stating the tool's purpose. It distinguishes from siblings like 'binance_us_account_info' by focusing exclusively on credit line data, not general account information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: for institutional users with approved credit facilities. It warns '⚠️ REQUIRES INSTITUTIONAL CREDIT LINE AGREEMENT' and specifies this API is only available to such users, providing clear usage prerequisites and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively communicates critical behavioral traits: the tool requires institutional agreements, affects LTV ratios (with specific directional impacts), has financial risk implications, and includes status responses (SUCCESS, PENDING, FAILED). It doesn't cover rate limits or authentication details, but provides substantial risk context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (warnings, prerequisites, transfer types, response format) and uses bullet points effectively. While comprehensive, it could be slightly more concise by combining some warning elements, but every sentence adds value for this high-risk financial operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-risk financial transfer tool with no annotations and no output schema, the description provides substantial context: risk warnings, prerequisites, transfer type explanations, and response format details. It doesn't cover authentication or rate limits, but given the schema's completeness and the tool's complexity, it provides adequate guidance for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some context about transfer types (TRANSFER_IN adds collateral, TRANSFER_OUT withdraws) which complements but doesn't significantly expand beyond the schema's parameter descriptions. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Execute a transfer') and target resource ('in or out of the credit line account'), distinguishing it from sibling tools like 'binance_us_cl_account' (info) and 'binance_us_cl_transfer_history' (history). It goes beyond the name/title by specifying the directionality of transfers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (for credit line transfers) and when not to use it (requires institutional credit line agreement). It includes prerequisites (checking LTV ratio, available amounts) and distinguishes from alternatives by focusing on credit line operations rather than regular account transfers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses important behavioral traits: the API key requirement ('REQUIRES CUSTODIAL SOLUTION API KEY'), performance implications ('can be slow'), and response format details. However, it doesn't mention pagination, rate limits, or error conditions that would be helpful for a production tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. The warning emojis and response format details are useful but could be more structured. Every sentence earns its place, though the response format listing could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no output schema, the description provides good context: purpose, prerequisites, usage warnings, and response format. It covers the essential information an agent needs, though additional details about error handling or rate limits would make it more complete for a financial API tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds marginal value by emphasizing the 'symbol' parameter recommendation ('Recommended to always specify') and warning about performance without it, but doesn't provide additional semantic context beyond what's in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get all open custodial trade orders') with the resource type specified. It distinguishes itself from sibling tools like 'binance_us_open_orders' (non-custodial) and 'binance_us_cust_get_order' (gets a specific order) by specifying 'custodial' scope and 'all open' nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use ('Get all open custodial trade orders') and when not to use ('Do not call without a symbol parameter as it returns all pairs and can be slow'). It also implicitly distinguishes from alternatives by specifying the custodial nature versus non-custodial sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that liquidations occur 'when LTV exceeds liquidationLTV threshold,' explains the data returned (assets, amounts, timestamp, LTV, fees), and includes a warning about institutional requirements. However, it lacks details on rate limits, authentication needs, or pagination behavior, which would be helpful for a read-only historical tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose and critical warning. Each sentence adds value: defining liquidation context, listing record fields, and specifying use cases. There is no redundant or verbose content, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description does a good job covering the tool's purpose, prerequisites, and return data structure. It explains what liquidation means and what fields to expect, which compensates for the lack of output schema. However, it could improve by mentioning response format (e.g., JSON array) or error handling, keeping it from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (startTime, endTime, limit, recvWindow). The description does not add any parameter-specific details beyond what the schema provides, such as explaining how timestamps relate to liquidation events or typical limit usage. Baseline 3 is appropriate when the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'liquidation history for credit line account,' distinguishing it from siblings like 'binance_us_cl_account' (general account info) or 'binance_us_cl_alert_history' (alerts). It specifies the exact scope of historical liquidation events, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states '⚠️ REQUIRES INSTITUTIONAL CREDIT LINE AGREEMENT,' providing a critical prerequisite. It also lists specific use cases ('Review past liquidation events,' 'Understand liquidation patterns,' 'Audit risk management effectiveness'), guiding when to use this tool versus alternatives like general account or trade history tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: the requirement for a custodial API key, the ExpressTrade feature's auto-funding behavior, and the response structure. It also lists order types and their requirements, adding valuable context beyond basic functionality. A minor deduction because it doesn't mention potential risks, rate limits, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. Each section (warning, order types, ExpressTrade, response) adds essential information without redundancy. Sentences are direct and purposeful, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, no annotations, no output schema), the description does a strong job. It covers purpose, prerequisites, order type specifics, a key feature (ExpressTrade), and response fields. However, it lacks details on error handling, rate limits, or examples, which would be helpful for a financial trading tool, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description adds significant value by explaining parameter semantics for each order type (e.g., 'LIMIT: Requires timeInForce, quantity, price'), clarifying dependencies not obvious from the schema alone. It also details the ExpressTrade feature's impact on 'allowExpressTrade' and 'asset'. This compensates well, though it doesn't cover all 12 parameters individually.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Place a new trade order') and resource ('through the custodial solution'), distinguishing it from sibling tools like 'binance_us_new_order' (non-custodial) and 'binance_us_cust_cancel_order' (cancellation). The mention of 'custodial solution' provides precise differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Place a new trade order through the custodial solution') and includes a warning about prerequisites ('⚠️ REQUIRES CUSTODIAL SOLUTION API KEY'). However, it does not specify when NOT to use it or name alternative tools for non-custodial orders, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively describes key behavioral traits: the 60-minute expiration reset mechanism, the 30-minute recommended call frequency, the consequence of expiration (need to create new key), and authentication requirements ('requires API key but does NOT require signature'). It doesn't cover rate limits or error responses, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured: a clear purpose statement followed by critical warnings in a bullet format. Every sentence earns its place - the first states the action, the warnings provide essential operational guidance, and the authentication note is crucial. No wasted words, front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations and no output schema, the description provides excellent context about when and how to use it, behavioral expectations, and authentication requirements. The only minor gap is the lack of information about return values or error conditions, but given the tool's simplicity and the comprehensive operational guidance, it's nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'listenKey' clearly documented. The description doesn't add any parameter-specific information beyond what the schema provides (no format details, examples, or constraints). Given the high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Extend the validity') on a specific resource ('a listen key') with precise timing ('by 60 minutes'). It distinguishes from sibling tools like 'binance_us_create_listen_key' and 'binance_us_close_listen_key' by focusing on maintenance rather than creation or termination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Call this every 30 minutes to prevent the stream from closing' tells when to use it, and 'If the key expires, you'll need to create a new one' tells when not to use it (implying this tool won't work on expired keys). It also implicitly references the 'create_listen_key' sibling as an alternative for expired keys.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses critical behavioral traits: the prerequisite (quote from another tool), time sensitivity (quote expiration), and response structure (orderId, createTime, orderStatus with defined values). However, it lacks details on permissions, rate limits, or error handling, which are important for a financial transaction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by important warnings and response details. Every sentence adds value: the first states the action, the second provides critical prerequisites, the third adds timing context, and the rest explain response fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial order placement tool with no annotations and no output schema, the description does well by explaining prerequisites, timing, and response structure. However, it lacks information about authentication requirements, potential side effects (e.g., fund movement), or error scenarios, which would make it more complete for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% with one parameter (quoteId), and the description adds minimal semantics beyond the schema's description. It mentions 'previously acquired quote' and 'quoteId' but doesn't provide additional context like format constraints or validation rules. With high schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Place an OTC trade order') and resource ('using a previously acquired quote'), distinguishing it from siblings like 'binance_us_otc_quote' (which provides quotes) and 'binance_us_otc_get_order' (which retrieves orders). It precisely defines the tool's function without tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('You must first call binance_us_otc_quote to get a quoteId before placing an order') and provides timing guidance ('place the order immediately after receiving the quote'). It clearly differentiates from the sibling tool 'binance_us_otc_quote' as a prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively communicates that this is a read-only diagnostic operation ('Test connectivity') that returns an empty object on success, which covers the key behavioral aspects for a simple connectivity check tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences that each earn their place: the first states the purpose, the second explains the return behavior. There is zero wasted verbiage, and the most critical information (what it does) comes first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter connectivity testing tool with no output schema, the description provides adequate information about purpose and return behavior. However, it doesn't mention potential error responses or authentication requirements, which could be relevant for a complete understanding of API connectivity testing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the baseline would be 4 even with no parameter information in the description. The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's purpose and behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Test connectivity') and target resource ('Binance.US API'), distinguishing it from all sibling tools which perform various trading, account, and data operations rather than connectivity testing. It provides a complete picture of what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests using this tool to verify API connectivity before attempting other operations, which provides clear context. However, it doesn't explicitly state when NOT to use it or name specific alternative tools for different purposes, keeping it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively discloses key behavioral traits: the requirement for a custodial solution API key (addressing auth needs), the institutional context, and the structure of the response (including specific balance fields like 'inSettlement' for custodial accounts). However, it lacks details on rate limits, error handling, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose and critical warning. Every sentence adds value: the first states the action, the second provides a crucial prerequisite, the third clarifies the target audience, and the rest detail the response format without redundancy. It's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple input schema, the description does a strong job covering purpose, usage, and response structure. It explains what the tool returns (balances with specific fields) and the institutional context. However, it lacks details on error cases or operational constraints like rate limits, which could be useful for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter 'rail', specifying it as 'Custodial partner name (e.g., ANCHORAGE, BITGO). Must be uppercase.' The description adds context by mentioning examples like Anchorage and BitGo, reinforcing the schema's guidance. With high schema coverage, the baseline is 3, but the description enhances understanding slightly, warranting a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get balance information') and resources ('Binance.US exchange wallet and custodial sub-account'), distinguishing it from sibling tools like 'binance_us_account_info' or 'binance_us_custodial_balance' by specifying it's for institutional custody partners and includes both wallet and custodial account balances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (for institutional custody partners like Anchorage or BitGo) and when not to use it (standard API keys will not work). It also implies alternatives by noting the custodial requirement, differentiating it from non-custodial balance tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively communicates critical behavioral traits: the locking of assets ('Staking locks your assets for a period of time'), the need for balance verification, and the default behavior for autoRestake. However, it does not mention potential errors, rate limits, or authentication requirements, which are common for financial operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, starting with the core purpose, followed by important warnings, parameter details, and response information. Every sentence serves a clear purpose, with no redundant or unnecessary content, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a staking operation (financial, with locking periods) and the absence of annotations and output schema, the description does a good job covering key aspects: purpose, prerequisites, parameters, and response structure. However, it lacks details on error handling, rate limits, or specific authentication needs, which are important for a complete understanding in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description adds value by providing context for each parameter: it explains that 'stakingAsset' refers to supported assets (e.g., BNB, ETH), clarifies the purpose of 'amount' in the staking context, and notes the default behavior for 'autoRestake'. This enhances understanding beyond the schema's technical definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Stake a supported asset') and resource ('on Binance.US') with the explicit goal ('to earn staking rewards'). It distinguishes itself from siblings like 'binance_us_staking_asset_info' or 'binance_us_staking_unstake' by focusing on the staking operation itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool, including prerequisites ('Check unstakingPeriod using binance_us_staking_asset_info before staking', 'Ensure you have sufficient balance', 'Verify min/max staking limits') and references to alternative tools (e.g., 'binance_us_staking_asset_info'). This helps the agent understand the proper context and conditions for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively describes key behavioral traits: the listen key validity period (60 minutes), maintenance requirements (use keepalive tool every 30 minutes), consequences of expiration (stream closes), account limitations (only one active key), and authentication requirements (API key needed, no signature). It also details what data the stream provides (account balance, deposit/withdrawal, order/trade updates).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficiently organized. It starts with the core purpose, provides critical usage information in a bulleted format, and ends with authentication details. Every sentence earns its place, with no redundant information. The warning section effectively highlights important behavioral constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (WebSocket stream setup with maintenance requirements) and the absence of both annotations and output schema, the description provides comprehensive context. It covers purpose, usage guidelines, behavioral details, limitations, and authentication requirements. The description fully compensates for the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately explains that no parameters are needed for this operation, which aligns with the empty input schema. No additional parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new listen key') and resource ('for User Data Stream WebSocket connection'), distinguishing it from siblings like binance_us_keepalive_listen_key and binance_us_close_listen_key. It explicitly mentions the purpose is for subscribing to real-time account updates via WebSocket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (to create a listen key for WebSocket connections) and when to use alternatives (use binance_us_keepalive_listen_key every 30 minutes to extend validity). It also mentions prerequisites (requires API key but no signature) and limitations (only one active listen key per account).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Binance-US-MCP MCP server](https://glama.ai/mcp/servers/nirholas/Binance-US-MCP/badges/card.svg)](https://glama.ai/mcp/servers/nirholas/Binance-US-MCP)

Score Badge

Copy to your README.md:

[![Binance-US-MCP MCP server](https://glama.ai/mcp/servers/nirholas/Binance-US-MCP/badges/score.svg)](https://glama.ai/mcp/servers/nirholas/Binance-US-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nirholas/Binance-US-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server