binance-mcp-chainvector

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
With 196 tools, there are many overlapping and confusingly similar tools, such as BinanceWalletWithdrawHistory and its V1/V2 variants, and multiple ticker tools like BinanceTicker24hr, BinanceTicker, BinanceTickerTradingDay, BinanceTickerPrice, and BinanceTickerBookTicker. An agent would likely misselect between these without deep reading of descriptions.
Naming Consistency2/5
Naming is highly inconsistent: Binance tools use PascalCase with mixed verb placement (BinanceAllOrders, BinanceNewOrder, BinanceGetOrder, BinanceKlines), while ChainVector tools use camelCase (chainvectorMomentum). Also, some tools have a 'register' prefix, and one (getSolStakingQuotaDetails) has no prefix, making the pattern unpredictable.
Tool Count1/5
196 tools is far beyond any reasonable MCP scope, even for a combined Binance and ChainVector server. This makes the set unwieldy and likely to be split into several focused servers, as the count alone overwhelms navigation and selection.
Completeness3/5
The server covers a vast number of Binance wallet, market data, and algorithm order endpoints, and the ChainVector analytics suite is thorough. However, core futures trading operations are missing: there is no standard futures order placement, position retrieval, or cancel for regular futures orders, only algorithmic orders. This leaves a significant gap for a trading-focused tool set.
Average 3.4/5 across 196 of 196 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
Add a glama.json file to provide metadata about your server.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects. The word 'Retrieve' implies a read-only operation, but the required setup parameters suggest this actually creates or modifies a resale configuration. This is a serious behavioral ambiguity with no mention of permissions, reversibility, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, so it is concise in length, but the phrasing is awkward and misleading. It is not as minimal as a tautology, but it fails to clearly convey the action, making it less effective than a well-structured sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 7 parameters, no output schema, and no annotations. The description does not explain the actual operation (create vs. retrieve), the return value, prerequisites, or any behavioral details. It is severely incomplete for the complexity involved.
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 coverage is 100% and each parameter has a clear description. The tool description adds little beyond listing the same parameters, so it stays at the baseline of 3. It does not enrich understanding of parameter relationships or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Retrieve a request' but then lists parameters needed to set up a resale, suggesting this is actually a creation operation. It also does not distinguish from sibling tools like BinanceHashRateResaleDetail, which likely retrieves an existing request by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. With a large family of hash rate resale tools (List, Detail, Cancel), the description should clarify that this is for creating or retrieving a specific request, but it provides no such context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose whether the tool has side effects. The name 'register' suggests a state-changing operation, but the description describes a read-only 'view'. This contradiction misleads agents about the tool's behavior. No mention of permissions, irreversibility, or output details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loads the resource, but it is vague and misleading due to the name mismatch. While it avoids waste, it lacks the precision needed for effective tool invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is inadequate for an agent to properly select and invoke this tool. It does not explain what 'register' means, what the API returns, or how it differs from related staking tools. The absence of an output schema and annotations makes the description the primary source of context, and it fails to deliver.
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 clearly described as 'Time window for request validity'. The description adds no additional parameter semantics, but the schema already provides sufficient meaning, so 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.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it allows users to 'view' SOL staking account details, but the tool name is 'registerBinanceSolStakingAccount', implying creation/registration. This is misleading and fails to state an accurate verb for the tool's action. The description also does not distinguish it from sibling tools like BinanceGetSolStakingHistory or BinanceSubscribeSolStaking.
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, scenarios, or exclusions. The only content is a functional description with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, what the response contains, or any side effects. The brief phrase 'Get open symbol list' offers no behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but it is under-specified to the point of vagueness. It does not earn its place because it communicates almost nothing beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should clarify what 'open symbol list' means and what the result looks like. It fails to provide enough context to understand the tool's purpose or differentiate it from similar-sounding tools.
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, and the schema has no properties. The description does not need to explain parameters, and the baseline for zero parameters is 4, as there is nothing to add beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Get open symbol list.' which names a verb and resource but leaves 'open symbol' undefined. It could refer to trading symbols, open orders, or something else, and does not distinguish from siblings like BinanceGetOpenOrders or BinanceWalletGetSymbolsDelistScheduleForSpot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only says 'Get asset details,' which implies a read operation but does not disclose what is returned, whether it requires authentication, or any other behavioral traits. This is no more informative than the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, but it is under-specified rather than concise. It restates the tool name and does not earn its place by adding useful information. Proper conciseness should front-load meaningful content, which is absent here.
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?
The tool has only 2 parameters, but no output schema and no annotations. The description should at least clarify what 'asset details' means, but it does not. Given the complexity and the presence of many sibling tools, the description is inadequate for selecting and invoking the tool correctly.
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 both parameters: 'asset' is described as 'Asset symbol' and 'recvWindow' with its constraint 'The value cannot be greater than 60000'. Since the schema provides full parameter meaning, the description does not need to add more, and the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get asset details' is essentially a tautology of the tool name BinanceWalletAssetDetail. It does not specify what kind of details, which asset, or how it differs from sibling tools like BinanceWalletUserAsset or BinanceWalletFundingWallet.
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. There is no mention of prerequisites, use cases, or exclusions. With many wallet-related sibling tools, the lack of usage context leaves the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Get user assets', which conveys a read operation but gives no information about authentication requirements, rate limits, response structure, or any side effects. This is far too little to be transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but under-specified. It is a single phrase with no wasted words, but it omits essential context, making it more a case of under-specification than effective 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?
The tool has no output schema and no annotations, yet the description doesn't explain what 'user assets' includes, how the optional parameters affect results, or anything about the return value. Given the complexity of the Binance wallet API and the numerous sibling tools, this description is 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?
Schema description coverage is 100% for both parameters (recvWindow and needBtcValuation), with descriptions provided in the input schema. The tool description adds no parameter details, but the baseline of 3 applies when the schema already covers the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Get user assets' is essentially a restatement of the tool name BinanceWalletUserAsset. It identifies a get operation but does not specify what kind of assets, which sub-account/wallet type, or how it differs from many sibling tools like BinanceWalletAllCoinsInformation or BinanceWalletQueryUserWalletBalance.
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. It does not mention any exclusions, prerequisites, or context where another tool would be more appropriate. The description is a bare phrase with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It doesn't mention required permissions, rate limits, response format, or any side effects. The description is purely a simple action statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no unnecessary words, but it is under-specified and adds no value beyond the tool name. It is concise in structure but lacking in substantive content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters including time range and limit, no output schema, and no annotations. The description does not explain what the snapshot includes, how time/limit interact, or what return value to expect. It is inadequate for correct 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?
All 5 parameters have schema descriptions, so the baseline is 3. The tool description adds no semantic information beyond the schema, so it remains at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a daily account snapshot, but it merely restates the tool name and doesn't distinguish it from sibling wallet tools like BinanceWalletAccountInfo or BinanceWalletUserAsset. No additional details about what the snapshot contains.
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?
There is no guidance on when to use this tool versus other wallet endpoints. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral traits beyond the basic 'get' action are disclosed. With no annotations provided, the description carries full responsibility, but it doesn't explain if this returns a list, paginates, requires specific time ranges, or any other behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words, but it is under-specified to the point of providing minimal value. It is concise but not substantial enough to be considered effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the only source of context beyond the parameter list. A one-sentence description fails to explain the tool's role, return format, or edge cases, making it inadequate for a tool with 5 optional parameters.
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 provides descriptions for all 5 parameters, giving the agent full parameter-level information. Since the description itself adds no parameter semantics, the baseline score of 3 applies.
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 uses the verb 'Get' with the resource 'asset dividend record', clearly indicating a retrieval operation. However, it does not distinguish this from related siblings like BinanceEarningsList or BinanceWalletAssetDetail, and it is ambiguous whether 'record' is singular or plural.
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 instead of alternatives. It lacks any mention of prerequisites, intended use cases, or distinctions from similar wallet/financial data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It merely rephrases the tool name without mentioning consequences like irreversible fund transfer, network fees, permission requirements, or that this is a real financial operation. The description adds no meaningful 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but this is under-specification rather than appropriate conciseness. For a tool with 10 parameters and high complexity, the description should include more context to be useful. It lacks front-loaded critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema, no annotations), the one-line description is grossly inadequate. It does not explain return values, prerequisites, risks, or operational details, making it incomplete for an AI agent to correctly invoke.
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 all 10 parameters having descriptions. Thus, the baseline is 3. The tool description does not add any extra parameter semantics beyond the schema, so it meets but does not exceed the baseline.
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 'Submit a withdraw request' clearly indicates the action (submit) and resource (withdraw request), which is specific enough for a withdrawal tool. However, it does not distinguish between this and sibling tools like BinanceWalletBrokerWithdraw or mention it's a crypto wallet withdrawal, so it lacks full 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?
There is no guidance on when to use this tool versus alternatives (e.g., withdraw history, fast switch, or broker withdraw). It simply states the action without providing context about prerequisites, alternatives, or when a withdrawal is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It only says 'Withdraw' and does not mention irreversibility, required questionnaire, fees, or security implications. This adds no value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only five words, which is extremely concise but at the cost of completeness. It is under-specified for a tool with 9 parameters and compliance complexity, making it more a placeholder than a helpful explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, 4 required, and no output schema or annotations, this one-sentence description is severely inadequate. It does not explain expected behavior, response format, or compliance details, leaving the agent to rely entirely on the 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 input schema has 100% description coverage, so every parameter has a basic description. However, the tool description adds no extra parameter semantics, such as how the 'questionnaire' should be formatted or how 'addressTag' differs from 'address'. Given high schema coverage, the baseline 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 uses the verb 'Withdraw' and the qualifier 'with travel rule compliance' to indicate the action. It distinguishes itself from the ordinary BinanceWalletWithdraw sibling by mentioning compliance, but it does not explicitly say it is for Binance wallet withdrawals or clarify what travel rule compliance entails.
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 the regular BinanceWalletWithdraw or other wallet tools. The description simply restates the tool's purpose without explaining when travel rule compliance is required or what prerequisites exist.
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 for behavioral disclosure. It states the action but does not explain side effects, such as whether enabling the switch changes withdrawal review processes, requires special permissions, or is reversible. There is no mention of risk or impact, making the behavior opaque for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short at four words, which is efficient, but it lacks a sentence structure and reads as a fragment. It earns no extra credit for details, and while there is zero waste, the brevity borders on under-specification rather than deliberate 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?
For a simple tool with one optional parameter and no output schema, the description might be adequate if it explained the switch's effect, but it doesn't. The tool is likely part of a wallet management API, and the description provides no context about what the switch does, when to use it, or what happens after enabling. The sibling tool names hint at a toggle pair, but the description itself is 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 has 100% coverage for the single parameter recvWindow, which is described as a number with a max constraint. The description does not mention the parameter at all, but since the schema is fully self-explanatory and there is only one parameter, the baseline of 3 is appropriate; the parameter's purpose (receive window for request timing) is standard and not clarified further by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Enable fast withdraw switch' clearly identifies the action (enable) and the resource (fast withdraw switch), which is distinct from the sibling tool 'DisableFastWithdrawSwitch'. However, it lacks specificity about the effect or scope of the switch, and without context it reads as a terse fragment rather than a complete sentence.
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 the disable counterpart or any other sibling. The description gives no context about prerequisites, timing, or intended use case, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description is a bare phrase that adds no behavioral detail. It does not disclose that this is a read operation, how pagination works, any auth requirements, or what the response contains. With zero annotation support, the description fails to inform the agent about non-obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the key verb and resource, but it is too terse to provide meaningful context. It is a single sentence without any structural breakdown of usage or behavior, sacrificing completeness for brevity.
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?
With 7 parameters, no output schema, and no annotations, the description should provide more context about return values, pagination behavior, and the 'travel rule' specifics. It lacks this entirely, making it incomplete for such a parameterized 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 input schema provides 100% description coverage for all 7 parameters, so the schema already explains coin, limit, offset, status, time ranges, and recvWindow. The description adds no parameter semantics, but the schema carries the burden, warranting the baseline score of 3.
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 uses a specific verb ('get') and identifies the resource ('deposit history for travel rule'). It distinguishes this tool from the sibling BinanceWalletDepositHistory by the 'travel rule' qualifier, though it does not explain what 'travel rule' means or explicitly contrast it with the non-travel-rule variant.
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?
There is no guidance on when to choose this tool over alternatives like BinanceWalletDepositHistory or BinanceWalletWithdrawHistory. No prerequisites, exclusions, or recommended use cases are 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?
With no annotations, the description only says 'get' and provides no disclosure of authentication requirements, return format, pagination, or status interpretation. It does not contradict the schema but adds minimal behavioral context beyond the operation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse and front-loaded with no filler, but it is under-specified for a tool with seven optional parameters. It reads more like a title than a specification, though it does not contain unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides virtually no context about the response structure, which is critical since no output schema is provided. An agent would not know whether this returns an array of deposits, how status codes are represented, or how pagination is handled, leaving a major gap for a wallet 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?
All seven parameters have detailed descriptions in the schema, so the baseline is 3. The description adds no additional meaning about how coin, status, time range, and pagination parameters interact, but the schema covers their individual meanings.
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 uses a specific verb (Get) and resource (deposit history), clearly stating the tool's basic function. However, it does not distinguish this from the closely-related BinanceWalletDepositHistoryTravelRule and mostly paraphrases 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?
No guidance is provided on when to use this tool versus alternatives like BinanceWalletWithdrawHistory or BinanceWalletDepositAddress. The usage is only implied by the name, with no explicit exclusions or alternative recommendations.
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 behavioral disclosure burden. It only restates the purpose without revealing key behaviors such as whether a list or single address is returned, the role of the optional network parameter, or any authentication/rate-limit considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with zero redundant words or filler. It is well-structured and front-loaded, effectively stating the core action 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 lack of annotations, output schema, and the tool name suggesting 'list' behavior, the description is underspecified. It does not explain the return format, the difference from related address tools, or any important constraints, leaving significant gaps for an agent trying to use the tool correctly.
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 provides complete descriptions for all three parameters (coin, network, recvWindow), so schema coverage is 100%. The description adds no additional parameter context, but the schema already offers sufficient meaning, making this the appropriate baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch deposit address with network' clearly indicates a verb and resource, but omits the 'list' aspect present in the tool name, making it ambiguous whether it returns a single address or a list. It also does not distinguish from the sibling tool BinanceWalletDepositAddress, which likely fetches a single deposit address.
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 such as BinanceWalletDepositAddress or BinanceWalletDepositHistory. The description does not mention any context, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 for behavioral transparency. It only says 'Query universal transfer history,' offering no details on read-only behavior, pagination, required parameters, time range handling, or response characteristics. It adds no behavioral traits beyond what the tool name implies.
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 short sentence that is front-loaded with the verb and object. It contains no fluff, but is a bit too terse; still, for conciseness, it is efficiently minimal.
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?
This is an 8-parameter tool with a required 'type' field, no output schema, and no annotations. The description is just a short phrase, giving no context for parameter interactions, required conditions, or expected results. It is far from complete for a tool with 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?
The input schema descriptions cover all 8 parameters (100% coverage), so the baseline is 3. The description itself adds no parameter information, but the schema already documents each parameter, including type requirements and time units, so no major gap exists.
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 queries universal transfer history, using a specific verb and resource. It does not explicitly differentiate from sibling tools like deposit/withdraw history queries or the transfer creation tool, but the name and description together make the purpose clear.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention the required 'type' parameter, pagination, time filtering, or any context for choosing this over other wallet history tools. The task provides no usage context at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits itself. It only says 'Get withdraw history (v2)' and does not mention that it is a read-only operation, how pagination works, authentication needs, rate limits, or any side effects. No behavioral context is added beyond the verb phrase.
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 concise phrase with no redundancy. It is front-loaded and easy to parse, though it is arguably too terse to stand alone. Overall, the sentence is appropriately sized for stating the basic action.
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?
The tool has 7 parameters, no output schema, and no annotations, placing a heavy burden on the description. The description only names the resource and version; it does not explain return values, pagination behavior, time/status semantics, or the difference from V1. The schema provides parameter details, but the description is otherwise 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?
All 7 parameters are documented in the schema with descriptions, so the baseline is 3. The description adds no parameter-level meaning, but it does not need to because the schema already covers all parameter semantics.
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 states a clear action ('Get withdraw history') and identifies the version ('v2'), which directly expresses the tool's purpose. However, it does not explain what distinguishes v2 from the sibling BinanceWalletWithdrawHistory or V1, so sibling differentiation is incomplete.
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 offers no guidance on when to use this tool over the many sibling history tools (e.g., BinanceWalletWithdrawHistoryV1, BinanceWalletDepositHistory). There is no mention of preferred use cases, prerequisites, or 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, the description carries full burden. It implies a read-only operation via 'Get' but discloses no behavioral traits such as response format, pagination, authentication, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and free of fluff, but it is under-specified. It is not a tautology, yet it lacks essential context that would make it appropriately informative.
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 absence of annotations and output schema, the description should clarify what 'information' entails. It doesn't, leaving the tool's purpose ambiguous and insufficient for an agent to invoke it confidently.
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 coverage for the sole parameter (recvWindow) is 100%, so baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides.
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 a 'Get' operation for 'information for all coins', providing a specific verb and resource. However, it doesn't differentiate from sibling tools that also retrieve coin-related data, relying on the tool name for 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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of appropriate scenarios, exclusions, or relationship to sibling wallet 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, the description carries full responsibility for disclosing behavioral traits. It merely states 'Submit,' implying a write operation, but offers no information about side effects, required permissions, or what response to expect. This is a significant gap for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is under-specified. It lacks structure that would help an agent parse the tool's behavior. While not verbose, it sacrifices necessary detail for brevity.
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 tool with no annotations and no output schema, the description is inadequate. It fails to explain what the questionnaire is for, what the response contains, or any compliance requirements. The sibling tool names provide hints but are not referenced or elaborated.
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 all three parameters have at least minimal descriptions. However, the tool description itself adds no parameter-level meaning beyond what the schema already provides, and the schema descriptions themselves are quite sparse (e.g., 'Transaction ID' and 'Travel rule questionnaire').
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 uses a specific verb 'Submit' and identifies the resource as 'deposit questionnaire for travel rule,' which clearly indicates the tool's function. It also distinguishes itself from the sibling tool BinanceWalletSubmitDepositQuestionnaire by explicitly mentioning 'travel rule,' though it remains unclear what a 'travel rule questionnaire' entails.
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 does not mention any prerequisites, situational context, or how it relates to sibling tools like BinanceWalletSubmitDepositQuestionnaire or BinanceWalletWithdrawTravelRule.
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?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It only mentions 'compressed, aggregate trades', offering minimal insight into pagination, time-filter behavior, or whether this is a public read operation. No details are given about response format or rate limits, leaving significant behavioral ambiguity.
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 sentence with no redundancy, front-loading the key action and object. It is appropriately concise, though slightly under-specified. No unnecessary words are present, so it earns a high score for conciseness despite the lack of 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?
With 5 parameters, no output schema, and no annotations, the description is too minimal to give the agent a complete picture. It doesn't mention return types, default behaviors, time range handling, or how aggregate trades differ from raw trades. The tool is relatively complex, and the description leaves substantial 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 covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds limited value by framing the data as 'compressed, aggregate trades', but it does not elaborate on parameter semantics beyond the schema. Thus, it neither enhances nor detracts significantly from the schema's clarity.
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 states a specific verb ('Get') and resource ('compressed, aggregate trades for a specific trading pair'), which clearly conveys the tool's function. The term 'aggregate' distinguishes it from similar trade-related tools like BinanceHistoricalTrades or BinanceGetTrades, though it could be more explicit about the aggregation concept.
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 BinanceKlines or BinanceHistoricalTrades. With many sibling market-data tools, the absence of usage context or exclusions leaves the agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states 'Get current average price' without explaining what 'average' means, potential rate limits, or response structure. This is minimal and leaves ambiguity about the tool's exact 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, direct sentence with no unnecessary words. It is front-loaded with the action and resource, making it easy to parse.
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?
Although the tool is simple, the lack of an output schema and minimal description leaves the return format and semantics unclear. It also fails to differentiate from similar price-related tools, making it incomplete for an agent to select correctly in a large sibling set.
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 covers 100% of the parameter with a clear description ('Symbol of the trading pair (e.g., BTCUSDT)'). The tool description adds no extra meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current average price for a trading pair, with a specific verb and resource. However, it does not distinguish this from sibling tools like BinanceTickerPrice, which likely also return a price. The scope is clear but differentiation is missing.
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 offers no guidance on when to use this tool versus alternatives such as BinanceTickerPrice or BinanceTicker. It does not state any exclusions or preferred contexts, leaving the agent to guess 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, the description carries the full burden of disclosing behavioral traits. It mentions the returned fields (transferred hashrate, daily hashrate, profit amount, payment status) but does not disclose pagination, default date ranges, or whether the list is ordered. It does not contradict annotations, but it leaves significant behavioral gaps for a read 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 a single, dense sentence that front-loads the main action ('Retrieves list of earnings') and then lists relevant data fields. Every word contributes value; there is no redundancy or filler.
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 tool has 8 parameters, no output schema, and no annotations, the description is too minimal. It lists some return fields but does not explain the overall response structure, pagination behavior, or how the date parameters (startDate/endDate) affect results. The description is incomplete for a complex 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?
Schema description coverage is 100%, and each parameter has a description in the schema. The tool description adds no additional parameter semantics beyond what the schema provides. Baseline 3 is appropriate because the description does not enhance understanding of parameters like algo or userName, but the schema already documents them.
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 it retrieves a list of mining earnings and specific data fields, but it doesn't explicitly distinguish itself from similar mining tools like BinanceMiningAccountEarning or BinanceHashRateResaleList. The verb 'Retrieves' and resource 'list of earnings' give clear purpose, but sibling differentiation is absent.
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 BinanceMiningAccountEarning. The description does not mention prerequisites, required parameters (algo, userName), or scenarios where this tool is preferred. Without this context, an agent cannot make an informed choice among the many mining-related 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?
With no annotations, the description carries the full burden for behavioral disclosure. The verb 'Get' implies a read-only operation, but the description does not explicitly state side-effect-freeness, auth requirements, or response format beyond the vague 'etc.'.
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?
One short sentence, front-loaded with the verb and resource. The trailing 'etc.' is slightly vague but does not significantly hurt 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?
The tool has no annotations and no output schema, so a fuller description of behavior and return values would be valuable. The current description gives only a high-level list of contents and does not clarify how optional parameters filter results or what the response looks like.
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 documents all three parameters with 100% coverage, so the baseline is 3. The description adds no extra parameter semantics; it only mentions 'symbol configs' broadly without explaining how symbol, symbols, or permissions affect the response.
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 uses the specific verb 'Get' with the resource 'exchange information' and lists example contents ('rate limits, symbol configs'), making the core purpose clear. However, without explicitly contrasting with sibling tools (e.g., BinanceTicker, BinanceWalletAccountInfo), it does not fully distinguish itself.
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 the many sibling tools. It only states what it retrieves, not use cases, 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 must disclose behavior. 'Get' implies a read operation, but the description does not state what data is returned, whether authentication is required, or if there are any side effects. Given the many similar account tools, this lack of detail means the agent cannot infer the tool's exact scope or safety profile.
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, concise sentence with no filler. It is front-loaded with the action verb 'Get' and the resource 'current account information'. While minimal, it is appropriately sized for a simple read operation, though it could include more specificity without becoming verbose.
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 large number of account-related sibling tools (BinanceWalletAccountInfo, BinanceWalletAccountStatus, BinanceWalletBalance, etc.) and the absence of an output schema or annotations, the description is insufficiently complete. It does not clarify what 'account information' encompasses or how this endpoint differs from similar ones, leaving the agent without enough context to invoke it correctly.
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 coverage is 100% because the only parameter recvWindow has a description ('The value cannot be greater than 60000'). The tool description itself adds no additional parameter context, but the schema already documents it sufficiently. Baseline of 3 applies.
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 'Get current account information' uses a clear verb and resource, making it understandable. However, it does not distinguish from sibling tools like BinanceWalletAccountInfo or BinanceWalletAccountStatus, which may also return account-related details. The term 'current account' is not explicitly scoped to spot trading, leaving ambiguity.
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 whether this is the primary account endpoint for spot trading or how it relates to other account-related tools in the sibling list. No exclusions or prerequisites are stated.
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 uses 'retrieve,' implying a read-only operation, but does not mention authentication requirements, potential side effects, rate limits, or what the response contains beyond 'available quotas.' This leaves critical behavioral traits undisclosed.
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 sentence that front-loads the core purpose and adds relevant context about personal and daily limits. It avoids unnecessary fluff, though the phrase 'API allows users to' is slightly verbose. Overall, it is 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?
The description covers the basic purpose and includes useful context about limits, which is important for a quota-checking tool. However, it lacks information about the response structure, any required authentication, or how to interpret the quotas. Given the absence of an output schema and annotations, more context would be expected.
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 only one parameter, recvWindow, and its description ('Time window for request validity') is covered 100%. The tool description adds no additional meaning or usage details for this parameter, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves current ETH staking and redemption quotas with a specific focus on personal and daily limits. The verb 'retrieve' and resource 'available ETH staking and redemption quotas' make the purpose unambiguous. However, it does not explicitly differentiate from other staking-related sibling tools such as BinanceEthStakingAccount, though the quota focus provides enough specificity.
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 does not provide any guidance on when to use this tool versus alternatives. It simply states what it does without mentioning use cases, prerequisites, or exclusions. This leaves the agent without context to decide between this and other staking/redemption 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 must carry the full burden of behavioral disclosure. It only states that it gets recent trades, without revealing whether authentication is required, whether the data is public, or any rate limits or return format details. This is minimal and insufficient for a tool with no annotation 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 a single, front-loaded sentence with zero wasted words. It is concise and easy to parse, though it could be slightly expanded to include key behavioral details without losing efficiency.
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?
With no output schema, no annotations, and a short description, the tool is under-specified. It fails to clarify the type of trades returned (public vs. private, spot vs. futures) or the meaning of 'recent' relative to sibling tools like BinanceHistoricalTrades. The ambiguity makes it incomplete for an agent to select confidently among the many related trade 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?
The input schema already has 100% coverage with descriptions for both parameters (symbol and limit), so the baseline is 3. The description adds no extra meaning beyond the schema; 'trading pair' simply restates the 'symbol' parameter without elaborating on format or behavior.
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 uses a specific verb ('Get') and resource ('recent trades for a specific trading pair'), clearly indicating the action and target. However, it does not explicitly differentiate from sibling tools like BinanceAggTrades or BinanceMyTrades, leaving some ambiguity about whether these are public market trades or user-specific trades.
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. It does not mention that BinanceHistoricalTrades might be better for older trades or BinanceMyTrades for user-owned trades, leaving the selection process to the agent's inference.
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 the full burden. It only restates the core function and does not disclose pagination behavior, default parameters, response format, or any edge cases. For a query tool, this lacks important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. It front-loads the purpose effectively, though it could be slightly more direct without the API framing.
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?
The description provides only high-level purpose and omits critical details like pagination size/current semantics, response structure, and behavior when time range is omitted. Given no output schema and no annotations, this is insufficient for an agent to fully understand the tool's behavior.
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?
Input schema coverage is 100%, so the schema already documents each parameter. The description adds no extra meaning beyond 'within a specified time range,' which is already evident from startTime/endTime fields. Baseline 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 retrieves historical WBETH exchange rates and BETH annual percentage rates over a time range, using a specific verb ('retrieve') and resource ('WBETH rate history'). It distinguishes from sibling tools like rewards or wrap history by specifying the data types, but it does not 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 is provided on when to use this tool versus alternatives such as BinanceGetWbethRewardsHistory or BinanceGetWbethWrapHistory. The description only implies usage for retrieving historical rate/APR data, with no clear 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?
With no annotations, the description carries full responsibility for behavioral disclosure. It only indicates a read operation ('Get') but does not explain how 'older' is determined, pagination behavior (fromId), or return format, providing minimal 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?
A single, front-loaded sentence with no wasted words. It efficiently communicates the tool's core purpose without redundancy.
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?
While the tool is simple, the description lacks key context like how to paginate, what order trades are returned, and why to choose this over similar trade endpoints. With no output schema or annotations, the description is insufficient for fully informed 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?
Input schema covers 100% of parameters with descriptions (symbol, limit, fromId), so the description does not need to add parameter detail. It adds no extra meaning beyond the schema, meeting the baseline for full 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?
Description states a specific verb ('Get') and resource ('older historical trades') with scope ('specific trading pair'), clearly indicating the tool's function. It distinguishes from recent-trade tools like BinanceGetTrades by the word 'older', though it does not explicitly differentiate from BinanceAggTrades.
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 given on when to use this tool versus alternatives such as BinanceAggTrades or BinanceGetTrades. The description only states basic function, leaving the agent to infer usage context.
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 only says 'get' data, but does not mention response format, pagination, time range handling, or any API-specific constraints. This is a significant gap for a data retrieval 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 a single concise sentence with no wasted words. It is front-loaded with the essential verb and object.
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?
Without an output schema, the description fails to explain what the returned candlestick data contains (e.g., OHLCV fields). Sibling differentiation is absent, and the tool has 5 parameters. The description is under-specified for an agent to confidently invoke and interpret results.
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 parameters are already documented. The description adds a slight mapping by mentioning 'trading pair' and 'interval', but does not go beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Get candlestick data (klines) for a specific trading pair and interval.' It is specific enough, but does not distinguish itself from sibling tools like BinanceUiKlines, which likely serves a similar purpose.
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. It does not mention BinanceUiKlines, BinanceHistoricalTrades, or other market data tools, leaving the agent without context for selecting the correct one.
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 only says 'Get,' implying a read operation, but does not mention pagination, response size, rate limits, or what data is actually returned. This is minimal at best.
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, front-loaded sentence with no wasted words, making it very concise. However, it is arguably too terse for a tool with 6 parameters and a niche domain like SOR allocations, so it loses a point for balance.
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 tool has no output schema, no annotations, and a specialized subject (SOR allocations), the description is far too sparse to provide sufficient context. It does not explain what SOR allocations are, how to interpret results, or when to use the filters.
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 provides descriptions for all 6 parameters (100% coverage), so the description correctly does not repeat them. However, it adds no additional semantic context about how parameters like allocationId or fromAllocationId interact or when to use them, so baseline 3 applies.
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 uses a specific verb 'Get' and a specific resource 'SOR allocations for Self-Trade Prevention,' clearly stating the tool's function. However, it does not differentiate this tool from closely related siblings like BinanceMyPreventedMatches or BinanceMyTrades.
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, nor are there any prerequisites or context for when SOR allocations would be needed. The description simply states what it does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'Get trades' and does not mention authentication requirements, pagination, or that it returns only the current account's trades.
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, focused sentence with no redundancy or fluff. It is appropriately concise, though it omits useful context that would make it more helpful.
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 absence of annotations, an output schema, and the presence of 7 parameters, this one-sentence description is inadequate. It does not explain return values, parameter relationships, or typical use cases, leaving significant 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 provides 100% coverage with descriptions for all 7 parameters, so the schema already explains the parameters. The tool description does not add further semantic meaning, warranting the baseline score of 3.
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 retrieves trades for a specific account and symbol, using a direct verb ('Get') and resource ('trades'). It distinguishes itself from public market-data tools by emphasizing the account scope, though the account isn't an explicit parameter.
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 vs. alternatives. With many similar Binance trading tools (e.g., BinanceAllOrders, BinanceGetTrades), the description offers no context for selecting this 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 present, and the description only uses the verb 'create', implying a state-changing action without detailing risks, required permissions, rate limits, or response behavior. For a trade-execution tool, this is a significant transparency 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 a single, front-loaded sentence with no wasted words. Though it is under-specified for such a complex tool, it is concise and easy to parse.
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?
With 11 parameters, no output schema, and no annotations, the description is insufficient. It does not explain behavior such as price being required for limit orders, the distinction between quantity and quoteOrderQty, or what the response contains, leaving the agent without essential 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 coverage is 100%, so the schema already documents all 11 parameters with descriptions. The tool description adds no extra meaning beyond echoing the 'symbol' parameter concept, so baseline 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 action (create) and resource (a new order on Binance for a specific trading pair). It distinguishes from read/delete tools but does not explicitly differentiate from other order-creation variants like OCO or TWAP order tools.
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 for when to use this tool versus alternatives. The description does not mention when a standard order is appropriate, nor does it point to other order types (e.g., OCO, TWAP) as 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 the full burden of behavioral disclosure. It only says 'UI-optimized' without specifying what that entails (e.g., adjusted formatting, different data granularity, or limits) and does not disclose any side effects or return behavior beyond what the schema shows.
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 sentence, front-loaded with the main action 'Get UI-optimized candlestick data.' However, the modifier 'UI-optimized' is vague and not elaborated, making it concise but not fully informative.
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?
The tool has five parameters, no output schema, and no annotations. The description does not explain the return format, the meaning of 'UI-optimized,' or how this differs from BinanceKlines, leaving significant gaps for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no extra meaning about parameters; it does not mention limits, time range semantics, or how 'UI-optimized' affects parameter interpretation.
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 uses a specific verb 'Get' and identifies the resource 'candlestick data' for a trading pair and interval. The qualifier 'UI-optimized' hints at a distinction from the sibling BinanceKlines but does not explicitly clarify how, so it is clear but lacks 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 BinanceKlines or other market data tools. It does not mention alternatives, prerequisites, or exclusions, leaving the agent to guess the appropriate context.
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 the full burden of behavioral disclosure. It only states the operation without disclosing what data is returned, whether permissions are required, or any other behavioral traits. For a getter, this is minimal but not misleading.
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, direct sentence that is easy to parse and front-loads the action. It is not verbose, though it could be criticized for being under-specified rather than appropriately concise.
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 abundance of similar sibling tools and no output schema, the description does not explain what 'account information' includes or how it differs from alternatives. This is insufficient for an agent to confidently select this 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 single optional parameter 'recvWindow' is already documented with its constraint. The description adds no additional meaning about the parameter, but the baseline of 3 applies.
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 uses a specific verb 'Get' and names the resource 'Binance Wallet account information', making the core action clear. However, it does not distinguish this from siblings like BinanceWalletAccountStatus or BinanceWalletUserAsset, which could also be interpreted as '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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many similar wallet account-related sibling tools. No context, conditions, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description provides minimal behavioral disclosure. It implies a read-only operation via 'Get' but does not mention return format, potential errors, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no redundant wording. It conveys the core function immediately.
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?
The description fails to explain what 'account status' includes or what the response contains. With no output schema and no annotations, this leaves the agent without enough information about expected return values.
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 only parameter 'recvWindow' is described in the schema with a constraint (≤60000) but not its purpose. Since schema coverage is 100%, the baseline of 3 applies; the description adds no additional parameter context.
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 states a specific action ('Get') and resource ('Binance Wallet account status'), making the core purpose clear. However, it does not differentiate from sibling tools like BinanceWalletAccountInfo or BinanceWalletDailyAccountSnapshot, leaving the exact scope of 'status' ambiguous.
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 usage context, prerequisites, or alternative tool guidance is provided. The description merely states what it does without explaining when to choose it over similar 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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the action itself, omitting any effects, reversibility, permission requirements, or consequences of disabling the fast withdraw switch, which is a significant gap for a potentially impactful wallet setting.
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 concise sentence, 'Disable fast withdraw switch,' with no redundant words or filler. It is front-loaded and efficiently conveys the core action.
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 simple schema (one optional parameter) and lack of output schema, the tool is low complexity. However, the absence of annotations and any explanation of the switch's significance or side effects leaves the description incomplete for safe and informed 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?
The input schema's single parameter (recvWindow) has a description ('The value cannot be greater than 60000'), achieving 100% schema description coverage. The tool description adds no additional information about the parameter, so the baseline of 3 applies because the schema handles the semantics.
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 'Disable fast withdraw switch' clearly states the action using a specific verb and resource. It distinguishes itself from the sibling 'BinanceWalletEnableFastWithdrawSwitch' through the opposite verb, though it does not explicitly reference that alternative.
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 (e.g., the enable counterpart), no prerequisites, and no context for the 'fast withdraw switch' concept. It offers no situational or conditional information.
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. The verb 'Get' implies a read-only operation, but the description does not disclose any additional behavioral traits such as auth requirements, rate limits, or the structure of the response. It provides minimal behavioral context beyond the verb itself.
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, focused sentence that directly states the tool's purpose. It is concise and front-loaded with no wasted words, earning its place.
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?
The tool is simple, but the description lacks context about the return value (no output schema) and does not clarify how this tool differs from other wallet balance tools. The sibling list is extensive, and the description provides no contextual anchors to help an AI agent choose it correctly.
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 all three parameters, so the schema already explains the parameters well. The description does not add any additional meaning to the parameters, which aligns with the baseline of 3.
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 (funding wallet balance). It is a specific verb+resource that is understandable. However, it does not differentiate from sibling tools like BinanceWalletQueryUserWalletBalance or BinanceWalletUserAsset, which could be similar.
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 instead of alternatives. The description does not mention context, prerequisites, or exclusions. Given the large number of wallet-related sibling tools, this is a significant gap.
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 does not state whether this is a read-only operation, what data it returns, or whether any special permissions are required. The verb 'Get' implies read-only, but the description lacks explicit safety or side-effect information.
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, concise sentence that states the core purpose without unnecessary verbosity. However, it is so brief that it omits useful context, making it efficient but not fully structured for an agent. It earns a 4 for being appropriately short, though it could include more guidance.
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?
With no output schema and no annotated safety information, the description needs to provide sufficient context for the agent. It lacks any information about return values, usage scenarios, or differentiation from similar wallet tools. The description is not complete enough for an agent to confidently invoke the tool correctly 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?
The input schema has one optional parameter, 'recvWindow', with a complete description ('The value cannot be greater than 60000'), providing 100% schema coverage. Per guidelines, this justifies a baseline score of 3. The description itself adds no additional parameter meaning beyond what the schema already conveys.
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 'Get API key permission' clearly identifies the action (get) and resource (API key permission), making the tool's basic purpose unambiguous. However, it does not differentiate this tool from sibling wallet tools like 'BinanceWalletAccountStatus' or 'BinanceWalletAccountInfo', which could also be related to API key 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions. Sibling tools like 'BinanceWalletAccountApiTradingStatus' or 'BinanceWalletAccountInfo' could overlap, but no distinction 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 must carry the behavioral burden. It only states a read-like action ('Get') but does not mention return format, authentication needs, rate limits, or side effects. The description adds no behavioral context beyond what the name implies.
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 sentence with no filler words. It is concise, front-loaded, and every word contributes to the purpose. There is no unnecessary structure overhead.
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 output schema and annotations, the description is quite sparse. It does not clarify what 'assets' means (e.g., dust, all spot assets) or explain the response format. While the tool is simple, the description could provide more context about its role in the conversion workflow, especially relative to related 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?
The single parameter recvWindow is fully described in the schema with a constraint (<=60000), so schema coverage is 100%. The description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and the resource 'assets that can be converted to BNB', clearly indicating the tool's purpose. It distinguishes from sibling tools like BinanceWalletUserAsset and BinanceWalletDustTransfer by focusing specifically on convertible assets, though it does not explicitly contrast with them.
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 about when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or exclusions. The description merely states the function without any contextual hints about when it should be invoked.
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 must disclose behavior, but it only says 'Get cloud mining payment and refund history.' It does not mention pagination behavior, required time-range constraints, return format, or any side effects/rate limits. 'Get' implies a read operation but that is the extent of 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 a single seven-word sentence with no filler, front-loaded with the verb. It is efficient, though arguably under-specified for a tool with five parameters.
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?
The tool has no output schema or annotations, and the description is a minimal phrase. It does not explain the returned data shape, pagination semantics, or time-window limits, leaving the agent with only schema field types. For a history endpoint with 5 parameters, this is insufficient 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 fully documents startTime/endTime/page/pageSize/recvWindow. The description adds no parameter semantics beyond what the schema already provides, so the baseline 3 applies.
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 states the tool retrieves cloud mining payment and refund history with a clear verb and resource. It is unambiguous and distinguishes the tool from other wallet/mining siblings, though it adds no detail beyond 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?
No usage guidance is provided. The description does not mention when to choose this over other wallet/history tools (e.g., BinanceWalletDepositHistory or mining earnings tools), nor any exclusions or prerequisites.
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 for behavioral disclosure. It only says 'Apply', implying a mutation, but does not disclose side effects, reversibility, required permissions, or expected response. This is a significant gap for a wallet 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 a single, front-loaded sentence with no wasted words. It is concise but at the expense of informative content; still, structure is efficient.
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 tool is a mutation with no output schema and minimal annotations, the description should explain the nature of the 'one-click arrival deposit' application, any prerequisites, and expected outcome. It does none of this, making it inadequate for the tool's 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%, with both 'recvWindow' and 'subAccountId' having descriptions. The tool description adds no parameter-specific meaning, but since the schema already documents them, baseline 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 action 'Apply' and the specific resource 'one-click arrival deposit', which distinguishes it from sibling tools like BinanceWalletDepositAddress or BinanceWalletDepositHistory. However, the meaning of 'one-click arrival deposit' is not expanded, so it is less explicit than 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 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, prerequisites, or alternatives. It does not mention context like sub-account requirements or eligibility, leaving the agent without information to choose this over other deposit-related 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 must carry the full burden of behavioral disclosure. It only mentions 'Query' (implying a read operation) but does not disclose details such as pagination behavior, rate limits, required permissions, or output format. This is minimal transparency for a tool with no safety annotations.
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 concise sentence that directly states the tool's function without any wasted words. It is appropriately front-loaded and easy to parse, though it is quite terse.
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 tool has 6 parameters, no annotations, no output schema, and a very brief description, it lacks important context such as the structure of the returned data, the meaning of 'delegation history', and edge-case behavior. The schema covers parameter formats but not the overall tool behavior or response 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% parameter coverage, with descriptions for all six parameters (page, email, limit, endTime, startTime, recvWindow). The tool description adds no additional parameter semantics beyond the schema, 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.
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 the resource 'user delegation history', which is specific and unambiguous. However, it does not explicitly differentiate this from sibling history-query tools like BinanceWalletQueryUserUniversalTransferHistory or BinanceWalletWithdrawHistory, 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 alternative history-query tools, nor any prerequisites or contextual scenarios. It simply states what the tool does without any usage 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, the description carries the full burden of behavioral disclosure. It only says 'Query,' which implies a read-only operation, but provides no details about authentication, response shape, data scope, or limitations. The wording essentially restates the tool name with no additional 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 a single concise sentence with no wasted words. It is front-loaded with the action and resource, though it lacks depth; that weakness is more a completeness issue than a conciseness issue.
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 output schema and no annotations, the description is too minimal to be contextually complete. It does not explain what the returned balance represents, whether it returns a list of assets or a single total, or how it differs from similar 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 coverage is 100% for the single parameter (recvWindow), so the schema fully documents it. The description adds no parameter-specific meaning, but the high schema coverage warrants the baseline score of 3.
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 the resource ('user wallet balance'), making the basic purpose understandable. However, it does not distinguish this tool from sibling tools like BinanceWalletUserAsset or BinanceWalletFundingWallet, which also provide balance-related information.
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 given on when to use this tool versus alternatives. With many sibling wallet and balance tools, the description provides no context, exclusions, or preferred 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?
With no annotations, the description carries full burden for behavioral disclosure. It does not mention that this is a write operation, any side effects, authentication requirements, rate limits, or what the response contains. The tool likely submits sensitive compliance data, yet no such context is provided.
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, well-formed sentence with no redundancy. It is appropriately concise for stating the core purpose, though it lacks any additional structure such as usage notes or parameter context.
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?
This is a 6-parameter tool with 5 required fields, no output schema, and no annotations. The description is insufficiently complete: it doesn't explain the travel rule context, the purpose of the questionnaire, the role of beneficiaryPii, or what happens after submission. Tool usage would be ambiguous without external knowledge.
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 coverage is 100%, but the parameter descriptions are terse (e.g., 'Signature', 'Deposit ID'). The tool description adds no extra meaning about parameter formats, relationships, or how to generate values like the signature. The baseline of 3 applies because the schema does provide basic descriptions for all parameters.
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 (submit) and the resource (deposit questionnaire), and specifies the context (broker deposit). However, it does not differentiate from the sibling tool BinanceWalletSubmitDepositQuestionnaireTravelRule, which appears to be a nearly identical 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?
There is no guidance on when to use this tool versus alternatives. No prerequisites, exclusions, or scenarios are described. The single sentence provides no usage context beyond the basic action.
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 only states 'Get trade fee' and reveals nothing about required parameters (despite symbol and recvWindow), return structure, authentication needs, or rate limits. This is insufficient for a tool that likely interacts with account-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 three words long, with no fluff or redundant information. It is maximally concise, though this brevity comes at the cost of 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?
The tool is simple (2 params, no output schema), but the description is too terse to be complete. It does not explain what the trade fee is (e.g., percentage, amount), whether it varies by symbol, or what the response format is. An agent would need additional context to use it confidently.
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 provides descriptions for both parameters (symbol and recvWindow) with 100% coverage. The description adds no additional meaning beyond the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get trade fee' uses a clear verb and resource, indicating the tool retrieves a trade fee. However, it does not distinguish itself from sibling tools like BinanceAccountCommission, which may also relate to fees, so it lacks explicit 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. There are no mentions of prerequisites, typical scenarios, or exclusions, leaving the agent to guess 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?
No annotations are supplied, so the description carries the full burden of disclosing behavior. It only states the action ('Make universal transfer') without noting potential side effects, required permissions, irreversibility, limits, or any other operational consequences. This is a significant gap for a mutating financial 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 a single sentence with no fluff, making it highly concise. It is front-loaded with the core action, but it is under-specified given the tool's complexity; however, that is more a completeness issue than a conciseness issue.
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?
This is a complex transfer tool with 6 parameters and no output schema, yet the description provides minimal context. It omits valid transfer types (e.g., spot to futures), restrictions, or what the response contains. Without annotations or output schema, the description is insufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, as every parameter has a description in the input schema, so the baseline is 3. The description itself adds no extra meaning about parameter usage, such as valid values for 'type' or the meaning of 'toSymbol'/'fromSymbol'. The schema descriptions are minimal, but the description does not compensate further.
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 'Make universal transfer between different accounts' clearly identifies the tool as a transfer operation between accounts, which is distinct from other wallet operations like deposits or withdrawals. However, 'universal' is vague and doesn't specify the types of accounts involved, so it's not fully 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. There is no mention of transfer types, prerequisites, or situations where this tool should be preferred over other transfer-related tools like BinanceWalletDustTransfer or BinanceWalletWithdraw.
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 but merely restates the tool's purpose. It does not mention pagination, return format, authentication, rate limits, or any behavioral traits beyond the fact that it retrieves history.
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 extremely concise at four words, with no wasted words. It is front-loaded and easy to understand, though it adds little beyond the tool name.
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 tool with 8 parameters and no output schema or annotations, the description is severely under-specified. It fails to explain what the history contains, how status or time filters work, or what the response looks like, making it inadequate for an agent to correctly invoke without additional inference.
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 baseline is 3. The description adds no parameter-level information, leaving all semantics to the schema. Parameter descriptions are terse (e.g., 'Withdraw status' without allowed values), but the description itself does not compensate.
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 uses a specific verb 'Get' and resource 'withdraw history', clearly indicating the tool retrieves withdrawal records. However, it does not distinguish from sibling tools like BinanceWalletWithdrawHistoryV1/V2 or DepositHistory, so it only achieves 4.
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 about when to use this tool versus alternatives, such as V1/V2 or related history endpoints. The description gives no context on filtering, time ranges, or whether this is the current version.
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 only states 'Get withdraw history (v1)' without revealing behavior like pagination limits, time range handling, filtering by status, or what the response contains. This is minimal and does not inform the agent about side effects or operation specifics.
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 extremely concise at six words, which is appropriate for a simple read operation. However, the brevity comes at the cost of missing useful context, so it is not a model of effective conciseness that balances density with informativeness.
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 tool with 7 parameters, no output schema, and no annotations, the description is too sparse. It fails to explain return values, parameter interdependencies, or the difference from the similarly named sibling tools. More context is needed to use the tool correctly in varied scenarios.
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 covers 100% of parameters with descriptions such as 'Coin symbol', 'Default 1000, max 1000', and 'Withdraw status'. The description adds no extra meaning beyond what the schema already provides, so it meets the baseline but does not compensate or 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 'Get withdraw history (v1)' uses a clear verb and resource, making the primary operation obvious. However, it does not differentiate from closely related siblings like BinanceWalletWithdrawHistory or BinanceWalletWithdrawHistoryV2, especially since a non-versioned BinanceWalletWithdrawHistory also exists in the sibling list.
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?
There is no guidance on when to use this tool versus alternatives such as BinanceWalletWithdrawHistoryV2 or BinanceWalletWithdrawHistory. The description does not mention any usage context, prerequisites, or exclusion criteria, so the agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it places TWAP orders, but doesn't disclose any operational details, side effects, prerequisites, or return 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, concise sentence with no redundant wording. It efficiently conveys the tool's primary function without wasting space.
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?
No output schema is provided, so the description should explain the response format or important execution details. It doesn't, leaving significant gaps for a complex TWAP order tool. The description also fails to mention how it relates to sibling algo order 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?
The input schema covers all parameters with rich descriptions (e.g., duration bounds, max notional, defaults), so the description need not add parameter details. However, the description also adds zero semantic value beyond the schema.
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 uses a specific verb ('place') and a specific resource ('TWAP algorithmic orders for USDⓈ-M Futures'), clearly distinguishing it from other order tools. The market specification adds precision.
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 alternate tools or conditions for selecting this TWAP order type, leaving usage completely undirected.
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 bears full responsibility for behavioral disclosure. It only states the basic action ('claim') without revealing side effects, idempotency, authorship requirements, rate limits, or what happens if rewards are already claimed. For a state-changing operation, 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 a single, concise sentence. It is front-loaded with the core verb and object. Minor redundancy exists ('Claim Boost Rewards' followed by 'claim their Boost APR airdrop rewards'), but it remains efficient and readable.
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?
This is a mutation tool with no annotations and no output schema. The description fails to explain the response format, possible errors, or the concrete effect of claiming. While the parameter schema is complete, the lack of behavioral and return-value information leaves the tool under-specified for an agent to confidently invoke it.
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 provides 100% description coverage for the only parameter (recvWindow), so the description is not required to add param details. The baseline is 3, and the description offers no additional meaning but also doesn't hurt.
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 action ('claim') and the resource ('Boost APR airdrop rewards for staking'). It distinguishes from sibling tools that only view rewards (e.g., BinanceGetBoostRewardsHistory, BinanceGetUnclaimedRewards) by indicating this is the claiming action.
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 like checking unclaimed rewards first (via BinanceGetUnclaimedRewards), nor does it exclude scenarios where claiming might not be appropriate.
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, the description carries the full burden. It discloses the response fields (amount, token type, status), but does not mention pagination, authentication requirements, rate limits, or that results are paginated. It is a read operation but lacks explicit disclosure of other behavioral aspects.
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 sentence that front-loads the purpose and then adds detail. It is efficient with no fluff, but could be more structured by separating the purpose from the return value description.
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?
The description does not compensate for the lack of output schema or sibling differentiation. It fails to mention pagination behavior, optional time filters, or how this tool differs from BinanceGetBoostRewardsHistory. For a tool with 6 parameters and no output schema, this is insufficient context for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 marginal value by giving examples of token type (SOL) and status values (CLAIM, DISTRIBUTE), but these are already present in the enum descriptions. No extra parameter semantics are provided.
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 retrieves historical boost rewards data for staking, including amount, token type, and status. It uses specific verbs and resource, but it does not distinguish this from the similarly named sibling BinanceGetBoostRewardsHistory, which appears to serve the same 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?
There is no guidance on when to use this tool versus alternatives such as BinanceGetBoostRewardsHistory or BinanceGetUnclaimedRewards. The description only states what the tool does, not when it should be chosen over other reward-related 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 the full burden of behavioral disclosure. It only says 'Retrieves a list' and lists some return fields. It does not mention pagination, sorting parameters, authentication requirements, or any potential side effects. This is a read operation, but the description does not explicitly confirm read-only behavior or disclose any limitations beyond what the schema already shows.
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, concise sentence that front-loads the main action ('Retrieves a list') and then lists key details. Every word adds value; there is no redundant or promotional content. It is 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters and no output schema, so the description should provide a robust overview. It lists some return fields, which is useful, but it does not mention pagination or sorting as features, nor does it differentiate from the sibling detail tool. Given that the schema covers parameters, the description is adequate but not thorough.
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 baseline is 3. The description does not add meaning to the parameters; it lists output fields, not input parameters. However, since the schema already explains every parameter (algo, userName, sort, etc.), the description does not need to compensate. The mention of 'miner name, status, real-time hashrate...' is about the response, not the request parameters.
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 'Retrieves a list of miners (workers) associated with a mining account', which is a specific verb and resource. However, it does not distinguish itself from the sibling tool BinanceRequestForDetailMinerList, which likely does something similar but with more detail. Thus it meets the 'clear but no sibling differentiation' level.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention when to prefer this over BinanceRequestForDetailMinerList or other miner-related tools. No exclusions or alternative suggestions are provided, leaving the agent without usage context.
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 only states that it 'initiates investment,' which hints at a financial commitment but fails to mention side effects like fund deduction, permission requirements, or potential irreversibility. This is a significant gap for a trading action.
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, front-loaded sentence that names the action, resource, and key inputs with no unnecessary words. The phrase 'with specified terms' is somewhat vague but does not significantly harm 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?
This is a financial action with no output schema and no annotations, yet the description provides no information about expected outcomes, error conditions, or related workflows. Given the complexity of investment products (e.g., auto-compound plan compatibility, product eligibility), the description is under-specified.
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 all five parameters, so the schema already documents meaning. The description only restates these parameters without adding new semantic details, matching the baseline of 3 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 specifies the action ('Subscribe') and the resource ('Dual Investment products'), listing the key required inputs (product ID, order ID, deposit amount, auto compound plan). This distinguishes it from sibling read operations like BinanceGetDualInvestmentProductList and BinanceCheckDualInvestmentAccounts, though it doesn't explicitly differentiate from the change-auto-compound tool.
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 a user wants to initiate a Dual Investment subscription and mentions the required identifiers. However, it does not state when not to use it, mention prerequisites (e.g., needing the product list), or reference alternatives such as registerBinanceChangeAutoCompoundStatus for modifying existing plans.
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 omits any information about side effects, authentication needs, execution semantics, or what happens upon placement. For a trade execution tool, this is a significant transparency 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 sentence that front-loads the key action and resource, with no filler or redundant information. It is perfectly 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?
The schema is rich, but the description lacks contextual details such as return behavior, order lifecycle, or relationship to other order types. For a complex trading API, this is minimally adequate but has clear gaps that could hinder correct 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?
The input schema has 100% coverage, with descriptions for all 9 parameters including enums and constraints. The description adds nothing beyond the schema, but since the schema does the heavy lifting, 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 action (place a VP order) and the resource (USDⓈ-M Contracts in Binance Futures). It does not distinguish this tool from sibling order-type tools like BinanceNewOrder, so it lacks explicit 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, no prerequisites, and no exclusions. It only states what the tool does, leaving the agent without decision criteria.
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 must carry the full burden of behavioral disclosure. The description only states the action ('Get') and the resource, without mentioning whether it requires special permissions, has side effects, returns current status, or other behavioral traits. This is a significant lack of transparency for an agent.
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 filler or redundant information. It is appropriately front-loaded and earns its place, making it highly 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?
The tool is simple with only one optional parameter and no output schema. The description explains its purpose but does not elaborate on the response format or distinguish it from similar account-related tools. Given the minimal complexity, it is adequate but leaves room for more context on usage and output.
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 sole parameter `recvWindow` is fully documented in the input schema with a description ('The value cannot be greater than 60000'), achieving 100% schema description coverage. The tool description adds no additional parameter context, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get account API trading status' clearly states a specific verb ('Get') and resource ('account API trading status'), which distinguishes it from sibling tools like BinanceWalletAccountStatus or BinanceWalletAccountInfo. However, it does not explicitly name alternatives or contrast with similar tools, so it earns a 4 rather than 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 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. There is no mention of prerequisites, conditions, or exclusions. The usage is only implied by the tool's name and purpose, but no explicit context 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 merely restates the tool's function without disclosing behavioral traits such as read-only nature, response format, or any rate limit implications.
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, focused sentence with no extraneous words. It is efficient and front-loaded with the core action.
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?
With no output schema and no annotations, the description does not explain the return structure (e.g., bids/asks arrays) or any ordering conventions. It is minimally sufficient but leaves gaps for an agent to know what to expect.
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%, and the description adds no additional parameter information. Baseline of 3 is appropriate since the schema already documents both 'symbol' and 'limit' with details.
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'), the resource ('order book depth data'), and the scope ('for a specific trading pair'). This distinguishes it from sibling tools like BinanceTickerBookTicker (best bid/ask) and BinanceKlines (candlestick 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 guidance is provided on when to use this tool versus alternatives. It does not mention related tools or scenarios where this should be preferred over other market data endpoints.
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 only states the retrieval purpose and some return fields, but omits authentication requirements, pagination behavior, rate limits, or response format 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 a single sentence that is front-loaded with the tool's purpose. There is minor redundancy ('Get SOL Staking History API' followed by 'retrieve their SOL staking history'), but it is otherwise compact and free of filler.
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 history retrieval tool with five parameters and no output schema, the description provides some useful return-field context (amount, BNSOL, exchange rate, status) but does not explain pagination, time-range parameters, or how optional filters affect results. It is minimally adequate but leaves 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% parameter description coverage, so the schema already documents all five parameters. The description adds no additional parameter semantics beyond what is in the schema, making the baseline score of 3 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 ('retrieve') and resource ('SOL staking history'), and specifies the data included (staked amount, BNSOL, exchange rate, status). This distinguishes it from sibling tools like BinanceGetSolRedemptionHistory and BinanceGetBnsolRewardsHistory.
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 related staking history/rewards tools. There are no explicit alternatives, exclusions, or prerequisites mentioned.
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 the full burden for behavioral disclosure. It only says 'Retrieves details' and lists content fields, but does not explicitly state that it is a read-only operation, whether it returns a single item or paginated list, or any permission/error behavior. The pagination and filtering behavior are left to the schema and not described.
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, tight sentence that begins with the verb and lists key included fields. Every word adds value, with no filler or redundancy.
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?
The tool has 5 parameters, no annotations, and no output schema. The description only states what data is returned but does not explain how parameters shape the result, describe the response format, or provide context for use. Given the absence of annotations and output schema, the description is insufficient for an agent to fully anticipate the tool's behavior.
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 each parameter having a description (e.g., 'Mining ID', 'Mining Account', page size/notes). The description does not add additional semantic meaning beyond the schema; it only mentions output fields, not how configId/userName constrain the query, so the baseline 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 identifies the verb ('Retrieves') and specific resource ('details of hashrate resale transactions'), enumerating the included fields (transferring/receiving subaccounts, algorithm, hash rate, date, income). This distinguishes it from sibling tools like BinanceHashRateResaleList by focusing on detailed data rather than a list.
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 such as BinanceHashRateResaleList or BinanceHashRateResaleRequest. The description does not mention prerequisites, exclusions, or scenarios where this tool is preferred, leaving the agent to infer usage from the name and schema.
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 disclosure burden. It only states 'Query open OCO orders for a specific account or symbol' but does not disclose whether symbol is optional, how pagination works, what the response contains, or whether this is strictly a read-only operation. The mention of 'specific account' is ambiguous given the schema only exposes a symbol parameter.
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 sentence that is front-loaded with the action and resource, containing zero wasted words. It is appropriately sized for the tool's simplicity.
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?
Despite low complexity (one optional parameter), the description omits crucial context: whether symbol is required, what the response looks like (no output schema), and how this relates to the authenticated account. It also lacks usage guidance and behavioral transparency, leaving the agent with incomplete information for correct invocation and interpretation.
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 coverage is 100% for the single parameter 'symbol', which already includes a clear example. The description adds no additional parameter-level meaning beyond what the schema provides, so the baseline 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 uses a specific verb ('Query') and resource ('open OCO orders'), clearly distinguishing it from the sibling BinanceGetOpenOrders which likely handles regular open orders. However, it does not explicitly name alternatives or explain the OCO distinction, so it is clear but lacks explicit 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for OCO-specific open order queries via the keyword 'OCO', but it provides no explicit when-to-use instructions, exclusions, or references to sibling tools. Users must infer when to choose this over BinanceGetOpenOrders or BinanceOrderOco.
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 the full burden of behavioral disclosure, but it only says 'Send a new OCO order.' It fails to explain what an OCO order does (one cancels the other), any side effects, order lifecycle, or constraints. No behavioral traits beyond the action are disclosed.
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, front-loaded sentence with no wasted words. It is appropriately concise for a tool that is otherwise well-documented through its schema.
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?
This is a complex order type with 11 parameters, no annotations, and no output schema. The description is far too minimal to provide complete context. It does not explain OCO semantics, how the limit and stop legs interact, or what the response contains, making it inadequate for an agent to fully understand the 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 baseline is 3. The description adds no parameter-level meaning beyond what the schema already provides. It does not clarify how parameters like stopLimitPrice or stopIcebergQty relate to OCO behavior, but the schema descriptions are sufficient for basic 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 tool sends a new OCO order on Binance, using a specific verb ('Send') and resource ('OCO order'). It distinguishes itself from sibling tools like BinanceNewOrder and BinanceDeleteOrder by naming the special order type.
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 about when to use this tool versus alternatives. It does not mention when an OCO order is appropriate, prerequisites, or that regular orders should go through BinanceNewOrder. The context of usage is entirely absent.
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 only states that it cancels an open order, but does not mention side effects, whether the action is reversible, permission requirements, idempotency, or error handling if the order is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, readable sentence with no redundant details. Slight filler like 'allows users to' could be trimmed, but overall it is concise and front-loaded with the core action.
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?
This is a relatively simple cancellation tool with two documented parameters, so a minimal description is acceptable. However, it lacks context on how to obtain the algoId (e.g., from a listing tool) or confirm the order is actually open, which leaves some room for ambiguity in 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% (both parameters have descriptions). The tool description itself adds no parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (cancel), the resource (an open TWAP algorithmic order), and the context (spot trading on Binance). It distinguishes from the futures variant (BinanceFutureCancelAlgoOrder) by explicitly saying 'for spot trading'.
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 given on when to use this tool versus alternatives, such as listing open orders first with BinanceSpotCurrentAlgoOpenOrders or using the futures counterpart. The description is purely definitional and does not specify prerequisites or when cancellation is appropriate.
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 discloses the read-only nature implicitly with 'retrieves', but doesn't describe pagination behavior (e.g., max page size 100), the meaning of 'all' with respect to time filters, or the response structure. It adds minimal behavioral context beyond the name itself.
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 sentence with no redundant words. It front-loads the key information: what it retrieves (historical SPOT TWAP orders) and from where (Binance). It earns a perfect score 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?
With 7 optional parameters, no output schema, and no annotations, the description is under-specified. It doesn't clarify how parameters like startTime/endTime or symbol interact, whether a symbol is needed, or what the returned data looks like. It also doesn't mention any constraints like data retention limits. This leaves significant gaps for an agent to use the tool correctly.
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 already provides descriptions for all 7 parameters, achieving 100% coverage. The description doesn't add any parameter-specific meaning beyond what the schema provides, so it meets the baseline 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 clearly states the tool retrieves historical SPOT TWAP orders from Binance, using a specific verb ('retrieves') and resource ('historical SPOT TWAP orders'). It distinguishes from sibling tools like BinanceFutureHistoricalAlgoOrder (future) and BinanceSpotCurrentAlgoOpenOrders (current open) by specifying 'historical' and 'SPOT'.
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 that it should be used for completed/closed TWAP orders or that current open orders should use BinanceSpotCurrentAlgoOpenOrders. No exclusions or alternative references.
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?
It discloses the core behavior: staking ETH to receive WBETH and providing the conversion ratio and staked amount. However, with no annotations and no mention of side effects, lock-ups, or API-specific behaviors, behavioral transparency is only partially covered.
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, front-loaded sentence with no filler. It efficiently conveys the action, result, and additional output information.
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?
With no annotations, no output schema, and a state-changing operation, the description leaves significant gaps: it does not explain what 'subscribe' means operationally, resolve the ETH/BETH discrepancy, or describe the expected response beyond amount and ratio. Additional behavioral context 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 descriptions already cover both parameters well (amount in BETH with 4-decimal limit, recvWindow as validity time). The description adds high-level context but introduces ambiguity by saying 'stake ETH' while the amount parameter is specified in BETH, which is not clarified.
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: to stake ETH and receive WBETH, along with the staked amount and conversion ratio. It distinguishes from other staking tools by specifying ETH staking, though it does not explicitly contrast with siblings like BinanceRedeemEth or BinanceWrapBeth.
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 such as BinanceRedeemEth or BinanceWrapBeth. The description implies usage for staking but lacks explicit context, 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 of behavioral disclosure. The description is a bare 'get' statement and does not disclose what statistics are included, how the response is structured, whether all symbols returns a large payload, or any rate-limit or error behavior. This is a significant gap for a tool with no annotation safety info.
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, front-loaded sentence: 'Get statistics for the current trading day for a symbol or all symbols.' Every word contributes to the purpose; there is no fluff or redundant phrasing. It is appropriately 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?
For a simple tool with one optional parameter and no output schema, the description is moderately complete. However, it does not enumerate what 'statistics' are returned, which is a notable omission given the many sibling ticker tools and the possibility that users need to know which fields are included. It is adequate but leaves gaps in return-value expectations.
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 already describes the 'symbol' parameter as 'Symbol of the trading pair (e.g., BTCUSDT)' with 100% coverage. The description adds the important semantic that the symbol is optional and that omitting it returns statistics for all symbols ('for a symbol or all symbols'). This goes beyond the schema and clarifies the tool's scope.
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 'Get statistics for the current trading day for a symbol or all symbols', which names the action (get), the resource (statistics for current trading day), and the scope (symbol/all). It is specific enough to suggest the 'current trading day' aspect distinguishes it from daily or rolling tickers, but it does not explicitly differentiate from sibling ticker tools like BinanceTicker24hr.
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 offers no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions or mention other sibling ticker tools (e.g., BinanceTicker24hr for rolling 24-hour stats). Usage context is only implied by the phrase 'current trading day', providing minimal guidance.
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 the full burden of behavioral disclosure. It only states the action and scope but does not mention important behaviors such as network dependencies, address generation rules, or required permissions. Provides minimal insight beyond the basic function.
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, front-loaded sentence that is concise and free of unnecessary words. It effectively communicates the core purpose without redundancy.
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?
The tool is a wallet operation with no output schema and no annotations. The description fails to mention nuances such as the optional network parameter's role, potential address regeneration behavior, or linkage to related address-list tools. Given these complexities, the description is too sparse to be fully 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 each parameter having a description ('Coin symbol', 'Network', 'The value cannot be greater than 60000'). The tool description itself adds no parameter detail, so the schema does the heavy lifting, consistent with 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 clearly states the tool gets a deposit address for a specific coin, using a specific verb ('get') and resource ('deposit address'). This distinguishes it from siblings like withdrawal or deposit history tools.
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 gives no explicit guidance on when to use this tool versus alternatives, such as when to use BinanceWalletFetchDepositAddressListWithNetwork or network-specific options. It only implies use for a single coin without exclusions or context.
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 the full burden of disclosing behavior. It merely states the action without detailing side effects, irreversibility, permission requirements, or what the conversion entails (e.g., selling small balances). This lack of behavioral context makes it hard for an agent to anticipate the tool's impact.
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 immediately conveys the tool's purpose. It is efficiently worded with no superfluous content, making it easy to parse and remember.
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 tool likely performs a real financial action (converting dust to BNB), the description lacks essential context such as what happens to the dust assets, whether the operation is irreversible, or what the response contains. Without an output schema or annotations, this minimal description is insufficient for an agent to fully understand the tool's behavior.
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?
Input schema coverage is 100%, with 'asset' described as 'Array of asset symbols to convert' and 'recvWindow' having a constraint. The description adds no extra meaning beyond the schema, meeting the baseline but not exceeding it.
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 'Convert dust assets to BNB' clearly states a specific action (convert) on a specific resource (dust assets) with a target (BNB). It distinguishes itself from sibling tools like BinanceWalletGetAssetsThatCanBeConvertedIntoBnb (which lists assets) and BinanceWalletDustlog (which shows logs).
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 checking which assets are convertible first or reviewing dust logs. It does not mention prerequisites or common use cases, leaving the agent to infer usage solely from the tool name.
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 the full burden of behavioral disclosure. It implies a read-only operation but does not explicitly state safety, authentication requirements, rate limits, or what the response contains. Minimal behavioral context is provided.
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, front-loaded sentence with no wasted words. It conveys the essential purpose efficiently.
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 no-parameter, no-annotation tool, the description is minimally adequate but lacks detail about the return format or content of the delist schedule. It doesn't explain what data the schedule contains, which could be important for an agent selecting and invoking the tool. However, the simplicity of the tool keeps it from being severely incomplete.
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, so the schema is fully covered and there are no parameter semantics to clarify. Baseline of 4 applies for no-parameter tools.
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 retrieves a delist schedule for spot symbols, using a specific verb and resource. It does not explicitly differentiate from sibling tools, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, no exclusions, and no context about typical use cases. The description simply states what it does without any usage 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 full responsibility for behavioral disclosure. 'Toggle' implies a mutation, but there is no mention of side effects, required permissions, reversibility, or what the response contains. This is a significant gap for a state-changing wallet operation.
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, front-loaded sentence with no redundant words. It immediately communicates the essential action and targets, making it highly efficient and easy to scan.
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?
Despite the simple parameter set, the lack of annotations or output schema means the description must explain return values, side effects, and usage context. It does none of these, leaving the agent without enough information to safely and correctly invoke the 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 input schema covers all parameters with descriptions, so the baseline is 3. The description echoes the two context parameters (spot trade, margin interest) but adds no new syntactic or semantic details beyond what the schema already provides.
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 'Toggle' and the resource 'BNB burn' with two specific contexts: spot trade and margin interest. It unambiguously distinguishes this tool from other Binance wallet tools like enable/disable fast withdraw switches or balance queries.
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, or any prerequisites or exclusions. The description only states what the tool does without contextualizing its use cases or edge cases.
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 the full burden of behavioral disclosure. It describes the data content but does not state whether this is a read-only query, how the history parameter affects the response, what the return format looks like, pagination, or any rate limits/authentication needs. The interpretive note about contrarian tells is useful but not 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?
Two concise sentences with no filler. The first sentence defines the data scope, and the second sentence provides a valuable contrarian interpretation. Every word earns its place, and the structure is front-loaded with the core resource.
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?
The tool has no output schema and no annotations, so the description should explain return values and behavior more completely. It does not mention how history mode changes the response, what the snapshot vs time series looks like, or how 'per venue' is represented in the output. The description is too thin for a 4-parameter tool with no structured output documentation.
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 coverage is 100%, so the baseline is 3. The description adds semantic context for the 'metric' parameter by explaining global vs top-trader ratios, which helps interpret the enum values. However, it adds little beyond the schema for 'history', 'interval', and 'symbol', which are already well-documented.
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 identifies the resource: ChainVector exchange-reported positioning with global account long/short ratio and top-trader account/position ratios per venue. It lacks an explicit verb like 'retrieves' or 'lists', but the data scope is specific and informative. It does not explicitly contrast with sibling tools like chainvectorLongShort, so it does not fully distinguish itself.
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 a usage context: crowded retail positioning against top traders is a contrarian tell, suggesting when the tool's data might be useful. However, it gives no explicit when-to-use or when-not-to-use guidance and names no alternative tools. This is implied rather than explicit.
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 must disclose behavior on its own. It explains the strategy rationale but fails to state what the tool actually returns (e.g., a direction signal, a score), how it handles cases where the minimum score isn't met, or whether it places trades. The imperative 'trade in the direction' is ambiguous about the tool's output 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 two concise sentences, front-loaded with the template name, and contains no filler. Every clause adds context about the strategy's logic and confirmation signal, making it appropriately sized.
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 tool has only two parameters and no output schema, the description leaves a critical gap: it never explains what the tool returns or how the output should be interpreted (e.g., 'long'/'short'/'neutral'). This is essential for using the strategy tool correctly, and the description's focus on strategy logic doesn't compensate for the missing operational detail.
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 already provides descriptions for both parameters, and the description adds minimal context by tying min_score to the 'aggregate squeeze score' and mentioning squeeze_direction as an output. It doesn't deepen understanding of parameter semantics beyond the schema, so it earns the baseline 3.
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 identifies this as a funding-squeeze strategy template and explains the trade direction logic, distinguishing it from raw funding/squeeze signal tools like chainvectorFundingSqueeze. However, it does not explicitly state that the tool returns a strategy signal or advice, instead describing the strategy logic in a directive manner.
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 a crowded side pays extreme funding and cascade risk confirms the unwind, but it does not explicitly state when to choose this over other strategy templates (e.g., chainvectorStrategyMomentum) or when not to use it. No alternatives are named, leaving selection guidance implicit.
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 the full burden of behavioral disclosure. It identifies the operation as a cancellation (implying a state change) but does not disclose whether the action is reversible, if confirmation is required, what happens on success/failure, or any permissions/rate limit considerations. This is a significant gap for a mutation 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 a single sentence that is concise, front-loaded, and contains no filler. Every word contributes to conveying the tool's purpose.
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 3-parameter tool with complete schema documentation, the description is minimally adequate. However, since there is no output schema and no annotations, the description should have provided more context about the cancellation's effects (e.g., permanence, idempotency). It conveys the core action but lacks depth expected for a destructive 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 documents all three parameters (configId as 'Mining ID', userName as 'Mining Account', recvWindow with constraints). The description adds no additional meaning beyond repeating 'mining ID and account details', which overlaps with the schema. Baseline 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 states a specific verb ('Cancel') and resource ('existing hashrate resale configuration'), which clearly identifies the tool's function. It also mentions the key inputs (mining ID and account details), distinguishing it from sibling tools like BinanceHashRateResaleList or BinanceHashRateResaleRequest.
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 implies the usage context (cancelling an existing resale configuration) but provides no explicit when-to-use or when-not-to-use guidance, nor does it reference alternative tools. For example, it does not mention that this should only be used for configurations created via BinanceHashRateResaleRequest or that the configuration must exist.
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 'retrieves', indicating a read-only operation, but does not disclose authentication requirements, rate limits, pagination behavior, or whether any side effects occur. The description adds minimal behavioral context beyond the operation type.
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, front-loaded sentence that communicates the essential purpose without any filler. It uses clear, specific language and does not waste 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?
For a list-retrieval tool with well-documented parameters, the description is minimally adequate. However, there is no output schema, and the description does not explain the shape of the returned list or any nuances like pagination limits, which the schema does partially cover. It also lacks clarity on what constitutes an 'algorithmic order' in this context, but this is somewhat evident from 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 baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides. It does not explain how parameters like symbol, startTime, or endTime are used together, but the schema covers their individual semantics.
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 action ('retrieves a list of past algorithmic orders'), the resource ('algorithmic orders'), and the market scope ('USDⓈ-M Contracts in Binance Futures'). This distinguishes it from sibling tools like BinanceFutureCurrentAlgoOpenOrders (current orders) and BinanceSpotHistoricalAlgoOrders (spot market).
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 BinanceFutureCurrentAlgoOpenOrders for open orders or BinanceSpotHistoricalAlgoOrders for spot. It does not mention any exclusions or prerequisites. The only implied usage is historical futures algo orders, but no explicit direction 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 must carry the burden of behavioral disclosure. It mentions the data returned (amount, token type, status) but does not disclose pagination behavior, time-range filtering, authentication requirements, or the read-only nature of the operation. The description adds minimal context beyond what the name implies.
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. Two sentences provide the core purpose and supporting details without unnecessary filler. Every word contributes to the meaning, 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?
While the schema covers parameters, the description lacks details about return structure, pagination defaults, or filtering behavior. It gives a partial view of the data (amount, token, status) but does not explain the full response or the effect of optional time-range parameters. Given the moderate tool complexity and absence of output schema, a score of 3 reflects the adequate but incomplete 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 six parameters with descriptions. The description adds no new semantic meaning beyond the schema; it echoes the type concept (CLAIM or DISTRIBUTE) but does not clarify size, current, or time parameters. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: to retrieve boost rewards history for staking activities. It specifies the resource (boost rewards history) and the action (retrieve), and distinguishes it from siblings like BinanceClaimBoostRewards (a claim action) and BinanceGetBnsolRewardsHistory (specific to BNSOL). The inclusion of reward details (amount, token type, status) further clarifies the 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?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It implies usage for staking activities but does not explicitly differentiate from other rewards history tools or explain when this specific endpoint is appropriate.
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?
While the description uses 'retrieve,' implying a read-only operation, it does not disclose authentication requirements, rate limits, or pagination behavior. In the absence of annotations, the description carries the transparency burden, but the read-only nature is explicitly stated and response fields are mentioned, offering moderate 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 a single, focused sentence that immediately states the tool's purpose and key output fields. It contains no redundant information and is well-structured for quick scanning.
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 historical data retrieval tool, the description provides enough initial context by listing response fields. However, with no output schema and no annotations, it does not fully address pagination, time filter usage, or how this fits into the broader staking workflow, leaving some gaps for the 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 input schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description does not add additional parameter context beyond what the schema provides, making the semantic value equal to the schema.
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 retrieves historical ETH staking redemption records, with a specific verb and resource. It mentions the asset type, amount, status, and time, providing a clear purpose, though it does not explicitly differentiate from sibling history tools like BinanceGetEthStakingHistory or BinanceGetSolRedemptionHistory.
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 BinanceGetEthStakingHistory or BinanceRedeemEth. It does not mention prerequisites, typical use cases, or exclusions, leaving the agent to infer usage solely from the tool name and description.
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?
Since no annotations are provided, the description carries the full burden for behavioral disclosure. It clearly frames the operation as a read ('Retrieves') and lists the data fields, which is helpful. However, it does not disclose pagination behavior, response shape, time-range semantics, or any access/rate-limit considerations, leaving notable 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 a single, front-loaded sentence that states the action and resource, followed by a compact enumeration of returned fields. There is no filler or redundancy; every clause contributes useful 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?
With no output schema and no annotations, the description should carry more weight; it lists key return fields but omits pagination defaults, response structure, and differentiation from nearby history tools. The schema covers the parameters well, but the overall tool context is only partially filled in.
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 parameters are already documented in detail. The description adds no substantive parameter semantics beyond what the schema provides, aside from reinforcing the buy/sell context already captured by the transactionType enum. The baseline 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 uses the specific verb 'Retrieves' with the resource 'fiat buy/sell payment history' and enumerates the returned fields, making the tool's primary function clear. However, it does not explicitly distinguish this from sibling history tools like BinanceGetFiatDepositWithdrawHistory or BinanceGetPayTradeHistory, so it stops short of 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description merely states what the tool does, with no exclusions, prerequisites, or comparison to sibling tools. An agent would have to infer applicability from the name and content.
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, the description carries the full burden, and it does disclose the return fields (network, transaction ID, contract address, token ID, fee, timestamps). However, it omits behavioral details like pagination behavior, time-range handling, or error responses, leaving some uncertainty about what to expect beyond the listed fields.
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 starts with the action verb 'Retrieves' and immediately identifies the resource. It lists useful return fields without redundancy, 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 read-only history tool with optional parameters and high schema coverage, the description gives a reasonable overview by listing return fields. However, without annotations or an output schema, it could be more complete by explaining pagination behavior or when to prefer this over sibling history 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 coverage is 100% and each parameter (page, limit, startTime, endTime, recvWindow) already has a clear description. The tool description adds no additional meaning to the parameters, so it stays at the baseline of 3 expected when the schema fully documents parameters.
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 it retrieves NFT withdraw history and lists key fields, making the tool's purpose specific and unambiguous. It distinguishes itself from sibling tools like deposit or transaction history through the 'withdraw' qualifier, though it does not 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?
The description provides no guidance on when to use this tool versus alternatives such as BinanceGetNFTDepositHistory or BinanceGetNFTTransactionHistory. It does not mention prerequisites, typical use cases, or exclusions, so users must infer usage from the name alone.
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 present, so the description carries the burden. 'Check status' implies a read operation, but the description does not disclose whether it modifies anything, whether an order ID is required, or what happens for nonexistent orders. It is minimal but not misleading.
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?
One sentence, directly states the action and scope, with no filler or unnecessary 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?
For a simple read tool, the description conveys the core purpose, but it omits the practical need for at least one order identifier (orderId or origClientOrderId) and any return details. Since there is no output schema, a bit more context would help an agent invokes it correctly.
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 covers all three parameters with descriptions, so the baseline is 3. The description only adds that the symbol is a trading pair, which largely repeats schema information; the need for either orderId or origClientOrderId is not clarified.
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 uses a specific verb 'Check' and identifies the resource as an order on Binance, scoped to a trading pair. It distinguishes from list-oriented siblings by focusing on a single order's status, 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 is provided on when to use this tool versus siblings like BinanceAllOrders, BinanceGetOpenOrders, or BinanceGetTrades. The context of checking a single order's status is implied, but no when/why or exclusions are 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 the full burden. It only states the basic retrieval action and the fields returned (amount, exchange rate). It does not disclose pagination behavior, time-range handling, authentication requirements, or any rate limits or edge cases, which are crucial without 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?
Description is a single, clear sentence with no redundant words. It is appropriately sized and front-loaded with the core purpose and key output details.
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 5 parameters (all optional), no output schema, and no annotations, the description provides minimal context. It explains the purpose and the type of data returned, but does not clarify pagination semantics, time-range filtering, or what the response structure looks like. However, the schema descriptions cover the parameters, so the description is adequate for a simple history retrieval tool but not comprehensive.
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 baseline is 3. The description does not add any meaning about parameters beyond what the schema already provides (size, current, startTime, endTime, recvWindow). It neither enhances nor contradicts schema info.
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?
Clear, specific verb+resource+scope. States it retrieves SOL redemption history and details the amount of BNSOL redeemed for SOL and the exchange rate. Differentiates from sibling tools like BinanceGetEthRedemptionHistory by explicitly targeting SOL.
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 does not mention alternative tools (e.g., for ETH redemption history) or any exclusions. It simply states what the API allows, leaving usage context implied.
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. While 'retrieve' implies a read-only operation, the description offers no details about pagination, data freshness, authentication requirements, or what 'unclaimed' means. It does not disclose any potential side effects or rate limits, leaving 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It front-loads the action and resource, making it easy to scan and 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?
The tool is simple with only one optional parameter and no output schema. The description is adequate but lacks context about the return format, what constitutes an unclaimed reward, and how this snapshot relates to historical staking data. Without annotations or output schema, more detail would be expected for full 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?
The schema covers 100% of the single parameter (recvWindow) with a clear description ('Time window for request validity'). The tool description does not mention the parameter, but the schema already provides sufficient meaning. Per the rubric, schema coverage above 80% yields a baseline 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 clearly states the tool retrieves information about unclaimed rewards from SOL staking activities, using the specific verb 'retrieve' and identifying the resource. This distinguishes it from other Binance staking tools like BinanceGetSolStakingHistory and BinanceGetBnsolRewardsHistory.
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. It simply states what it does but does not mention exclusions or contrast with sibling tools like BinanceGetSolStakingHistory or BinanceGetBoostRewardsHistory. Given the many similar staking-related tools, explicit usage context is missing.
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 only states what is returned, but does not mention pagination behavior (despite pageSize and pageIndex parameters), read-only nature, authentication requirements, or any rate limits. The field enumeration adds some context, but operational behavior beyond the basic return value is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that efficiently conveys the tool's purpose and key output fields. It contains no fluff or redundant phrasing, earning full marks for conciseness and structure.
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?
The tool is relatively simple with optional parameters and no output schema. The description covers the core purpose and return fields, which is adequate for a basic list operation. However, it lacks pagination details, usage positioning among sibling tools, and any mention of response structure or potential errors, so it is average 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%, as pageSize, pageIndex, and recvWindow are each described in the schema. The tool description adds no additional parameter meaning beyond what the schema already provides, so it meets the baseline 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 clearly states the tool returns a list of hashRate resale configurations and enumerates the specific transfer details included (algorithm, hashrate amount, sender/receiver usernames, dates, status). This distinguishes it from sibling tools like BinanceHashRateResaleDetail (single configuration) and BinanceCancelHashRateResaleConfiguration (cancellation).
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. It does not mention related tools such as BinanceHashRateResaleDetail for viewing a single configuration or BinanceHashRateResaleRequest for creating one, nor does it specify any 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 only says 'Get current order count usage' which implies a read-only operation, but it does not explicitly state that it has no side effects, whether authentication is required, or what 'each rate limit' means operationally. Minimal beyond the obvious.
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 concise sentence that is front-loaded with the action and resource. No wasted words, every word contributes to clarity.
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 one-parameter tool without an output schema, the description gives a general idea of the return value ('current order count usage for each rate limit') but lacks detail on the exact structure or interpretation. It is adequate but not fully comprehensive.
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 covers 100% of parameters (recvWindow has a description), so the baseline is 3. The description adds no additional semantic meaning to the parameter, relying entirely on the schema.
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 a specific verb ('Get') and resource ('current order count usage for each rate limit'), which distinguishes this tool from sibling order management tools like BinanceGetOrder or BinanceNewOrder. It unambiguously identifies 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 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 monitoring rate limits before placing orders or comparing with other rate-limit-related endpoints. There is no mention of exclusions or preferred use cases.
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, the description must carry the full burden. It implies a read-only operation via 'Get' and mentions the ability to fetch for all symbols, but it does not clarify whether both bid and ask sides are returned or describe the response structure. Some behavioral detail is present, but not comprehensive.
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?
A single, front-loaded sentence with no redundant words. The action and resource are immediately clear, and every word contributes to understanding the tool's purpose.
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 endpoint with one optional parameter and no output schema, the description covers the main purpose and scope. However, it omits explicit details about the return format (e.g., bid/ask quantities), which would help an agent fully understand what data to expect.
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 provides a complete description for the single 'symbol' parameter ('Symbol of the trading pair (e.g., BTCUSDT)'), achieving 100% coverage. The tool description adds no additional semantic meaning beyond what is already in the schema.
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 states a specific action ('Get') on a specific resource ('best price/quantity on the order book') with a clear scope ('for a symbol or all symbols'). It is informative enough to distinguish it from siblings like BinanceDepth or BinanceTickerPrice, though it does not 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 is provided on when to use this tool versus other ticker/depth tools. The optional symbol parameter is noted, but there is no context on use cases, exclusions, or alternatives, leaving the agent to infer when this is the right choice.
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 for behavioral disclosure. It implies a read-only operation, but does not state whether authentication is needed, how results are paginated, or any constraints like time range defaults.
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 a helpful parenthetical clarification. Every word earns its place with no redundancy.
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?
The tool is simple, but with no output schema and no annotations, the description is minimal. It explains what the tool returns at a high level but lacks details on return format, pagination, or default time window, leaving gaps for an agent to discover.
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 coverage is 100% for the three optional parameters (startTime, endTime, recvWindow). The description does not add meaning beyond what the schema already provides, so a baseline 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 tool retrieves a dust log, defined as history of dust transfers. This distinguishes it from the sibling BinanceWalletDustTransfer which performs the transfer, and from other wallet query tools.
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. It does not mention prerequisites, typical use cases (e.g., post-transfer audit), or situations where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full transparency burden. The 'Get' verb indicates a non-destructive read operation, which is useful, but no further behavioral details (e.g., authentication requirements, response contents, rate limits) are disclosed.
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, front-loaded sentence that wastes no words. It's appropriately sized for a zero-parameter status 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?
Despite being simple, the description lacks clarity on what 'system status' encompasses (e.g., API availability, maintenance windows) and does not provide an output format. The absence of an output schema increases the need for a slightly richer description, which is missing.
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?
There are no parameters, leaving no semantics to document. The description is not required to explain parameters, and the schema already covers this trivially.
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 uses the specific verb 'Get' with the resource 'Binance Wallet system status', clearly indicating a read operation. However, it doesn't differentiate from sibling tools like BinanceWalletAccountStatus, relying on the narrow 'system status' phrasing.
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 when-to-use or alternative guidance is provided. The description does not mention any prerequisites, exclusions, or contrast with related status/wallet tools.
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. The verb 'Get' implies a read-only operation, but the description does not explicitly state safety, authentication needs, or return format. It is adequate but lacks explicit 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 sentence that directly states the purpose with no filler or redundancy. It is perfectly concise and 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?
The tool is simple, with two parameters and no output schema, so the one-sentence description is mostly sufficient. However, it could clarify how it differs from similar fee-related sibling tools and what the response contains, making it slightly 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 input schema has 100% parameter coverage, with clear descriptions for 'symbol' and 'recvWindow' (including the max value constraint). The description adds no additional meaning beyond the schema, so the baseline 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 gets account commission rates for a specific symbol, using a specific verb and resource. However, it does not differentiate this from sibling tools like BinanceWalletTradeFee, so it stops short of 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 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. There is no mention of prerequisites, exclusions, or conditions under which this tool should be 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 bears the full burden. It discloses the core mutation (placing a limit order) but omits behavioral context like order execution behavior, required permissions, potential rejections, or the fact that funds may be reserved. For a trading tool, 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?
A single, front-loaded sentence conveys the core purpose without extraneous information.
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?
Despite a rich schema, the tool has no output schema and no annotations. The description does not explain the response structure, order lifecycle, or integration with sibling tools like BinanceConvertOrderStatus or BinanceConvertCancelLimitOrder, leaving gaps for a complex 9-parameter order placement 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 descriptions cover all 9 parameters, so the baseline is 3. The description adds minimal relational semantics by noting 'either base or quote amount' and grouping wallet type and expiry, but this largely mirrors existing 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 uses a specific verb ('Places') and identifies the unique resource ('limit order to convert between two tokens'), clearly differentiating from general order tools like BinanceNewOrder and other convert workflow tools.
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 its use case (placing a limit conversion order) but does not explicitly state when to choose this over alternatives such as BinanceNewOrder or when not to use it. No exclusions or alternative guidance 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the creation purpose but doesn't mention what the tool returns (e.g., a listenKey), that the stream expires, or that it requires authentication. These are important behavioral traits for a create operation, so the description 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 a single, well-structured sentence with no filler. It front-loads the verb 'Create' and conveys the essential information in 14 words, with every word earning its place.
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?
The description lacks important operational context. With no output schema, it should explain that the tool likely returns a listenKey needed for WebSocket connection, and that the stream must be maintained via PutUserDataStream and closed with DeleteUserDataStream. The absence of these details makes the tool incomplete for an agent to use correctly.
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 zero parameters, so the schema description coverage is 100%. Per the guidelines, a zero-parameter tool gets a baseline of 4. The description doesn't need to explain parameter details since none exist.
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 (create), the resource (new user data stream), and the purpose (receive account updates via WebSocket). This distinguishes it from sibling tools like BinanceDeleteUserDataStream and BinancePutUserDataStream, which handle deletion and keepalive respectively.
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. It doesn't mention that this is the first step in the stream lifecycle, nor does it reference the need for PutUserDataStream to keep the stream alive or DeleteUserDataStream to close it. The description leaves the usage context entirely implicit.
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 read-only nature ('check the status') and the return fields, which is helpful. However, it does not mention pagination behavior, rate limits, or that it might be restricted to VIP users beyond the phrase 'Allows VIP users'. It adds moderate context but lacks depth.
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. The first sentence states the primary purpose, the second lists the returned details. Every word earns its place, and there is no redundant 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?
For a simple read-only query tool with no output schema, the description adequately conveys what the tool does and what it returns. It mentions VIP-only access and typical response fields. Pagination can be inferred from schema parameters. It is slightly lacking in that it does not differentiate from similar VIP loan tools, but overall it is reasonably 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% for all three parameters (limit, current, recvWindow), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides, which is acceptable given the 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 tool checks VIP loan application status and returns a list of loan requests with specific details (loan coin, amount, term, collateral, status). It is specific about the resource (loan applications) and the action (check status), though it does not explicitly contrast with sibling tools like BinanceGetVIPLoanOngoingOrders.
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. It does not mention exclusions, prerequisites (e.g., VIP status), or scenarios where another tool would be more appropriate. The only hint is the verb 'check', implying a read-only query, but no explicit use-case 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions that the request is an HTTP POST, but does not disclose that redemption moves funds, may be irreversible, requires an existing position, or can fail due to insufficient balance. This is a significant gap for a financial write 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 a single sentence that is easy to parse and front-loaded with the action. However, the phrase 'using a programmatic HTTP POST request' is generic and adds little value for tool selection, though it does not detract much.
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 5 parameters and no output schema, the description is adequate for understanding the core purpose but lacks operational details such as return behavior, error conditions, and the relationship between amount and redeemAll. The schema covers parameter syntax but not the broader context of how redemption works.
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 provides descriptions for all five parameters (100% coverage), so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already states, such as how amount and redeemAll interact.
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 action ('redeem') and resource ('funds from a Flexible Earn investment product'), making it distinct from siblings like BinanceSubscribeFlexibleProduct and BinanceGetFlexibleProductPosition. The verb-resource pair is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when users want to redeem funds from a Flexible Earn product, but it does not explicitly mention when to use it versus alternatives or provide any prerequisites. No exclusions or context such as 'use after subscribing' or 'use to withdraw' 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 the full burden of explaining behavior. It uses the verb 'retrieves,' implying a read-only operation, but does not disclose rate limits, required permissions, pagination behavior, or what happens if the algoId is invalid. This is minimal transparency beyond the tool's name.
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 sentence with no unnecessary words, making it concise and easily scannable. However, it could include a bit more actionable context (e.g., that algoId is required) without becoming overly verbose, so it falls short of a 5.
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 simplicity (4 params, 1 required) and the fact that the schema covers all parameters, the description is minimally adequate. It does not mention related tools for alternative scenarios (e.g., futures sub-orders) or describe the response shape, but it does convey the essential purpose. No annotations or output schema puts more burden on the description, which it only partially meets.
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 provides full descriptions for all four parameters (page, algoId, pageSize, recvWindow) with 100% coverage. The description adds no extra parameter details, so the baseline score of 3 is appropriate. The schema already handles parameter semantics effectively.
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 function: it 'retrieves details of sub-orders associated with a specific algorithmic (Algo) order for spot trading on Binance.' This uses a specific verb ('retrieves'), names the resource ('sub-orders'), and differentiates from sibling tools like BinanceFutureSubOrders by explicitly mentioning 'spot trading'.
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 when to use this tool (when needing sub-order details for a spot algo order) but does not explicitly state alternatives or exclusions. It doesn't mention that BinanceFutureSubOrders should be used for futures or that BinanceSpotCurrentAlgoOpenOrders covers current open algo orders, so guidance is only implied, not explicit.
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 explaining tool behavior, but it only states that the tool returns OI history with per-venue or aggregated granularity. It does not disclose response format, pagination, default intervals, or any safety guarantees. The interpretive sentence addresses data meaning, not tool 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 two sentences, with the first sentence immediately stating the resource and scope, and the second adding valuable interpretive context. There is no extraneous wording or repetition of schema details. It is well-structured and quickly readable.
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?
The tool has no output schema and no annotations, leaving the description as the primary source of context, but it omits return structure, row fields, and behavior when no data is found. It provides interpretive meaning but not enough for an agent to know what to expect from the call. For a history tool with five optional parameters, this is 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?
All five parameters are documented in the schema with descriptions, so the description does not need to repeat them. The description's mention of 'per-venue or aggregated' aligns with the exchange parameter but adds no new detail beyond the schema's 'omit for all'. No additional parameter semantics 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 identifies the tool as providing ChainVector open-interest history, with a per-venue or aggregated scope. This distinguishes it from sibling tools like chainvectorLongShort or chainvectorPositioning, which cover other metrics. The interpretive note about OI versus price adds context but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for open-interest analysis by explaining how to interpret OI changes relative to price, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. No sibling tools are referenced for comparison, so guidance is implied rather than explicit.
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, the description carries the transparency burden. It clearly indicates a read-only operation via 'retrieve' and lists sample response fields. However, it omits pagination behavior, time-range semantics, and any authorization requirements.
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 sentence that is front-loaded and free of unnecessary content. It has minor redundancy with the tool name ('Get ETH Staking History' vs 'historical ETH staking records'), but remains 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?
The description partially fills the missing output-schema gap by naming some returned fields. However, it does not mention pagination via size/current or the time-range filter options, which are relevant for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for all five parameters, so the baseline is 3. The description does not add parameter-specific details beyond the schema, but implies time-based filtering consistent with startTime/endTime.
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 uses a specific verb ('retrieve') with a specific resource ('historical ETH staking records') and lists key return fields. It does not explicitly distinguish from sibling tools like BinanceGetEthRedemptionHistory, but the resource scope is clear enough.
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 historical ETH staking records are needed, but provides no explicit guidance on when to prefer this tool over alternatives such as BinanceEthStakingAccount or BinanceGetEthRedemptionHistory, and no exclusions or prerequisites.
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 must disclose safety and side-effect behavior. It only states the conversion outcome and does not mention that this is a fund-moving operation, whether it is irreversible, fee/rate behavior, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action. However, the second sentence largely restates the first, creating slight redundancy.
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 only two well-documented parameters, the description provides enough selection-level context. Still, without an output schema and no mention of what the API response contains or the delivery outcome of the SOL, it is only minimally 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%, so the baseline of 3 applies. The description adds the phrase 'based on the specified amount' but does not provide additional semantic detail about the amount format or recvWindow beyond what the schema already states.
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: 'redeem BNSOL and receive SOL in exchange.' This makes the tool's purpose unambiguous and distinguishes it from sibling staking/subscription tools like BinanceSubscribeSolStaking or BinanceGetSolRedemptionHistory.
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 intended use is implied by the description—use this when you want to redeem BNSOL for SOL—but no explicit when-to-use guidance or alternatives are provided. It does not mention when not to use it or how it relates to sibling redemption/staking 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, the description carries the full burden of disclosing behavioral traits. It adds that orders can be active, canceled, or filled, which is a minor clarification, but it does not mention read-only nature, pagination limits, possible time windows, or any side effects. This is a thin description for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It fully states the purpose and scope without any waste, earning a top score for conciseness.
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?
The tool is relatively simple, and the schema covers all parameters, but the lack of annotations and no output schema leaves some gaps. The description does not clarify whether this is spot-only or includes futures (sibling names suggest a distinction), nor does it hint at response size or result structure. For a 5-parameter tool with no annotations, this is adequate but not 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%, so the schema already documents all parameters (symbol, limit, startTime, endTime, orderId). The description does not add any parameter details beyond what the schema provides, so 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('all account orders') and clearly scopes to a symbol with statuses (active, canceled, filled). This distinguishes it from sibling tools like BinanceGetOrder (single order) and BinanceGetOpenOrders (only open 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 when you need the full order history rather than just open orders, but it does not explicitly state when to use this tool over alternatives or provide any exclusions. The agent must infer that this is the comprehensive order retrieval tool based on the wording 'all account orders' and the sibling names.
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 must carry the full burden. It states the tool provides a quote (read-only in nature) and implies a funds check, which is useful. However, it doesn't disclose whether this is a read-only operation, whether it locks funds or expires, how long quotes are valid (though validTime parameter exists), or any rate limitations. The behavior of 'quote' is not fully elaborated beyond rate and amount.
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 sentence, front-loaded with the core action 'Get a real-time quote', and includes essential qualifiers (convert, rate, amount, funds). It avoids unnecessary jargon and is immediately scannable.
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?
With 7 parameters, no output schema, and no annotations, the description needs to provide enough context for an agent to understand the tool's role. It explains what the tool does and a key precondition (sufficient funds). However, it doesn't explain the mutual exclusivity of fromAmount and toAmount (likely required), quote expiration semantics, or the difference between SPOT and FUNDING wallets. Given the presence of sibling tools for executing quotes and listing pairs, additional context would help.
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 fully documents each parameter with descriptions. The tool description adds the context of 'convert one token to another' and 'enough funds', which ties parameters together. However, it doesn't explain the relationship between fromAmount/toAmount (which must be provided as a pair) or the walletType distinction. Since schema covers individual params, a 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 gets a real-time quote for converting one token to another, including rate and amount, conditioned on sufficient funds. This is specific and actionable. However, it doesn't explicitly distinguish itself from sibling tools like BinanceConvertAcceptQuote, BinanceConvertGetListAllConvertPairs, or trade tools, which could cause ambiguity about whether this is a quote-before-trade tool.
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 a user needs to convert tokens and check sufficient funds, which is a clear context. However, it doesn't explicitly mention when NOT to use it or point to alternatives like BinanceConvertAcceptQuote (to actually execute the quote) or BinanceNewOrder for spot trading. The condition 'if you have enough funds' hints but doesn't provide a full decision framework.
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. However, it merely restates the tool's purpose ('Cancel an active order') without detailing irreversible effects, required permissions, or behavior if the order is no longer active. This is minimal and offers little beyond the tool's name.
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, concise sentence that is front-loaded with the core action. Every word earns its place, and it is appropriately sized for a simple cancellation tool.
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 output schema and no annotations, the description is somewhat under-specified for a mutation tool. It does not mention required permissions, error scenarios, or that orderId and origClientOrderId are alternative identifiers. However, the parameter schema is well-documented, partially compensating for the lack of behavioral 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 coverage is 100% with each parameter having a clear description. The tool description adds minimal semantic value, only reinforcing that the symbol identifies the trading pair. It does not clarify the optionality or relationship between orderId and origClientOrderId, but the schema already describes these 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 action (cancel), the resource (an active order on Binance), and the scope (specific trading pair). It distinguishes from sibling tools like BinanceDeleteOpenOrders, which cancels multiple open orders, and BinanceCancelAlgoOrder, which targets algo 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 use for canceling a single active order on a specific trading pair, but provides no explicit guidance on when to use it vs alternatives like BinanceDeleteOpenOrders, nor any prerequisites or exclusions. Usage context is implied but not directly stated.
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 must disclose behavioral traits. It only states that it 'retrieves' data, which implies a read operation, but it does not mention required permissions, rate limits, pagination behavior, or whether any side effects occur. For a retrieval tool, this sparse behavioral disclosure 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 a single, information-dense sentence that front-loads the verb and resource, then lists relevant bonus categories. There is no fluff or redundant phrasing.
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?
With 8 parameters, no output schema, and no annotations, the description should explain what the returned data looks like and how to use the parameters. It lists bonus categories but does not describe the response structure, pagination behavior, or date-range semantics. While schema descriptions cover parameter syntax, the overall context for a complete API invocation is lacking.
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 provides descriptions for all 8 parameters with 100% coverage. The description adds no additional parameter-level meaning—it focuses on the output categories. Therefore, it meets the baseline for schema coverage but adds no extra semantic 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 uses the specific verb 'Retrieves' and identifies the resource as 'extra bonuses related to mining activities', then enumerates distinct categories (merged mining, activity bonuses, rebates, smart pool bonuses, income transfers, pool savings). This clearly differentiates it from sibling tools like BinanceEarningsList or BinanceMiningAccountEarning, which focus on regular earnings.
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 does not explicitly state when to use this tool over alternatives, nor does it name exclusions or alternative tools. However, the specific mention of 'extra bonuses' and the list of bonus types imply that this tool is appropriate for retrieving supplementary mining rewards, providing a mild usage cue.
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 for conveying behavioral traits. The verb 'retrieve' implies a read-only operation, and it mentions the returned content types, but it does not explicitly state read-only semantics, auth requirements, rate limits, or pagination behavior. It is adequate but not rich.
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, front-loaded sentence with no filler. It efficiently communicates the tool's core purpose and key output fields, earning its place without unnecessary verbosity.
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?
The tool has no output schema, so the description should helpfully explain the return shape. It mentions asset conversion details, exchange rates, and transaction status, but it omits pagination/response structure and does not clarify how the optional time filters affect the results. It is minimally complete but leaves 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% parameter coverage, with each parameter (size, current, endTime, startTime, recvWindow) already described. The tool description adds no parameter-level detail, but because the schema is comprehensive, the baseline 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 uses the specific verb 'retrieve' and clearly identifies the resource: 'historical records of WBETH wrap operations.' It also lists the key returned data (asset conversion details, exchange rates, transaction status), making it distinct from sibling tools like BinanceGetWbethUnwrapHistory, BinanceGetWbethRateHistory, and BinanceGetWbethRewardsHistory.
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?
There is no guidance on when to use this tool versus the many similar history tools among its siblings (e.g., wrap vs unwrap history, rate history, rewards history). The description only states what the tool does, not when it should be chosen or when an alternative would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries full responsibility for behavioral disclosure. It only states the action 'Get' and gives no insight into pagination, required parameters, filtering behavior, or operational nuances. The description adds little beyond the tool's name.
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, front-loaded sentence with no redundant information. It is concise and to the point.
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 6 parameters and no output schema, the description is minimal but minimally viable. It identifies the purpose and relies on the schema for parameter details. Missing context includes how filters interact and typical use cases, but the basic selection criteria are met.
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 baseline is 3. The description does not add any parameter-specific meaning, but the schema already provides detailed descriptions for all six parameters, including defaults and constraints.
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 'Get prevented matches for Self-Trade Prevention' uses a specific verb and resource, clearly identifying a distinct endpoint. It differentiates from sibling tools like BinanceMyTrades or BinanceMyAllocations by focusing on prevented matches.
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 through the 'Self-Trade Prevention' context but provides no explicit guidance on when to use this tool versus alternatives. No exclusions or alternative tool recommendations are mentioned.
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 responsibility for behavioral disclosure, yet it only says 'Test connectivity' without mentioning whether the operation is read-only, possible side effects, response format, or error behavior. This is minimal and relies on the user's inference that a connectivity test is safe.
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, concise sentence that efficiently conveys the tool's purpose. There is no wasted wording, and the structure is front-loaded with the key action and target.
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 simplicity (zero parameters, no output schema), the description is somewhat adequate, but it lacks an explanation of what a successful 'test' returns or how connectivity is confirmed. For a trivial utility, this is a moderate gap; a more complete description would mention the expected success indicator (e.g., HTTP 200 or server time).
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, and the schema is empty with 100% coverage, so the baseline of 4 applies. The description adds no parameter details, but none are needed; the empty schema already conveys that no inputs 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 a specific verb ('Test') and resource ('connectivity to the Binance API'), which distinguishes it from the many trading and wallet operations among sibling tools. It is immediately obvious 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 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, nor any exclusions or prerequisites. With sibling tools spanning wallets, orders, and market data, explicit usage context would be valuable, but it is entirely absent.
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 is the sole source of behavioral information. It discloses the type of data returned (hourly and daily metrics), which is useful. However, it does not mention any prerequisites (e.g., mining account auth), potential errors, or whether the data is historical or real-time. There is no contradiction, but more context would be beneficial.
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, well-structured sentence that front-loads the primary action and then adds relevant detail. Every word is purposeful, and it is no longer than necessary to convey the tool's 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 the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is adequate for a basic retrieval tool. It explains what data is returned but lacks details on response structure, time ranges, or prerequisites. It is sufficient for an agent to understand the core function but not fully complete for nuanced 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 coverage is 100%, so the schema already documents all parameters with descriptions. The tool description adds some context about the metrics returned, which indirectly helps understand the purpose of parameters like workerName and algo, but it does not add substantial parameter semantics beyond the schema. Baseline 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 action ('Retrieves detailed hashrate data') and the resource ('a specific miner'), and specifies the granularity (hourly and daily) and example metrics (time, hashrate, rejection rate). This distinguishes it from sibling tools like BinanceRequestForMinerList, which likely lists miners.
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. It implies use for a specific miner's detail, but does not mention exclusions or alternatives, such as using a list tool first or a different tool for other data. The description leaves the context of use to be inferred.
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 for behavioral disclosure. It reveals that the tool subscribes (a mutation) but does not mention permissions, prerequisites, side effects, or response behavior. This is a significant gap for a transaction-like 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 a single clear, front-loaded sentence with no filler. Every word contributes to conveying the purpose and key optional parameters.
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?
The description is adequate for a simple subscription tool, but without annotations or output schema, it lacks context on what happens after successful subscription, error conditions, or request validity. It does not fully compensate for the missing structured 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. The description adds no extra semantic detail beyond naming productId, amount, and optional parameters, which does not exceed 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 action ('Subscribe to a Simple Earn Flexible Product') with specific parameters (product ID and amount). This distinguishes it from sibling tools like BinanceRedeemFlexibleProduct and BinanceSimpleEarnFlexibleProductList.
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 describing the subscribe action and mentions optional parameters, but does not explicitly state when to use this tool versus alternatives (e.g., when to subscribe vs. redeem). No exclusions or alternative tools are referenced.
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. 'Fetch' implies a read operation, but no explicit disclosure of side effects, required permissions, rate limits, or return format is given. The description adds no behavioral 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 a single, concise sentence with no unnecessary words. It is appropriately sized for a simple tool with no parameters, earns its place, and is easily scannable.
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 fetch tool with no parameters, the description is minimally adequate, but it lacks any additional context such as what the address list contains, whether it includes networks, or any usage context. Without an output schema, it also doesn't clarify return details. It's functional but lean.
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, and schema coverage is 100% (vacuous). Per the baseline for tools with no parameters, the description doesn't need to add parameter meaning. The baseline of 4 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 action ('Fetch') and the resource ('withdraw address list'), which is specific and distinguishes it from sibling tools like deposit address list or withdraw history. It uses a clear verb+resource structure.
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 exclusions, prerequisites, or related tools like BinanceWalletWithdrawHistory or BinanceWalletFetchDepositAddressListWithNetwork. Usage is only implicitly inferred from the name.
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 is the only source of behavioral information. It implies a read operation via 'Get' but discloses no details about authentication, pagination, rate limits, or the exact structure of the returned list.
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, concise sentence that directly conveys the tool's purpose without any fluff or redundancy.
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?
The tool is simple (0 params, no output schema), and the description states the core function. However, it lacks details about the response format, any required authentication context, or whether the list is full or paginated, leaving some gaps.
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, so there is no parameter semantics to explain. Baseline of 4 applies; the description adds nothing about parameters but none are needed.
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?
Description uses a specific verb ('Get') and resource ('list of onboarded VASPs'), clearly stating the tool's function. It distinguishes from sibling tools that focus on coins, deposits, or withdrawals.
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. It does not mention exclusions, prerequisites, or any context for selection.
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 transparency burden. It discloses the method (cross-correlation over a rolling window) and adds the behavioral insight that laggards follow within seconds. However, it does not describe output structure, data sources, or the fact that it is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no filler. The first sentence states the tool's function, and the second provides actionable context for interpreting results. Every word earns its place.
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 absence of an output schema, the description should clarify what the returned matrix contains (e.g., rows/columns, values, or ranking). It explains the concept and use case but leaves the exact output format ambiguous, which prevents a higher completeness 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?
Both parameters are fully described in the schema (100% coverage), so the description need not repeat them. The description adds no extra semantic detail beyond mentioning the rolling window, which already aligns with the 'window' parameter. Thus 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 identifies the resource (lead-lag matrix) and states its purpose: determining which venue's price moves first for an asset. It distinguishes itself from sibling tools by focusing on cross-venue lead-lag relationships, though it lacks an explicit action verb like 'computes' or 'returns'.
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: to identify leader venues and anticipate follower moves within seconds. However, it does not explicitly state when to use this tool over other chainvector analytics or provide exclusion criteria, earning a middle 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, the description carries the full burden. It explains the nature of the data (forced-closure events, side, USD size) and the interpretive significance, but it does not disclose operational behaviors like return format, pagination, rate limits, or whether it is a read-only historical query. The content context adds value but stops short of full 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 two concise sentences. The first sentence defines the tool's core function, and the second provides valuable trading context. Every word earns its place, and the structure is front-loaded with the primary purpose.
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?
The tool has no output schema and no annotations, so the description should compensate by explaining what the tool returns. It mentions side and USD size but omits other likely fields like venue and timestamp, and does not clarify whether the tape is historical or real-time. The parameters are well-documented in the schema, but operational details are missing, leaving the description only partially 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 already provides 100% coverage with descriptions for all three parameters (from, limit, symbol), so the baseline is 3. The description adds no parameter-specific details beyond what the schema provides, such as how 'from' and 'limit' interact or the default symbol behavior. It does mention 'venues' but that is not a parameter.
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 identifies the resource as a liquidation tape containing forced-closure events with side and USD size, which distinguishes it from other chainvector tools like open interest or funding. However, it lacks an explicit verb like 'returns' or 'lists', which makes the action less direct than ideal.
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 noting that long liquidation clusters mark capitulation lows and short-liq clusters mark blow-off tops, giving traders a reason to use the tool. However, it does not explicitly state when to use this tool over alternatives such as chainvectorLiquidationHeatmap, nor does it provide any exclusion criteria.
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 must carry the full burden of behavioral disclosure. It implies a read-only historical data operation but never explicitly states read-only status, side-effect freedom, pagination, rate limits, or authentication requirements. It does not contradict annotations (there are none), but it adds no behavioral context beyond the 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 a single sentence with a clear subject-action-object structure and a clarifying em-dash parenthetical. No redundant words or unsupported claims; it front-loads the main purpose without requiring multiple reads.
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?
There is no output schema, so the description should explain what the tool returns. It provides conceptual guidance ('calibration ground truth') but does not specify the response structure, fields, or pagination behavior. The schema documents parameters well, but given no output schema and no annotations, the description leaves some ambiguity about the exact data shape. For a relatively simple lookup tool, this is a moderate gap.
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 provides 100% parameter coverage with descriptions for limit, venue, and series. The description adds slight context by mentioning 'a series' and the notion of price-based calibration, but it does not explain limit defaults or venue semantics beyond what the schema already provides. Therefore, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns settled prediction-market outcomes for a given series, explicitly framing it as calibration ground truth. This distinguishes it from sibling tools like chainvectorPredictionsQuotes (quotes) and chainvectorPredictionsMarkets (markets) by focusing on realized outcomes. The verb 'settled' acts as a specific retrieval action, and the resource is well-defined.
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 the tool is for calibration analysis ('how often did YES actually win at each price?') but does not explicitly state when to prefer it over alternatives or exclude it from other scenarios. No sibling comparisons or conditional guidance is provided, leaving usage context largely implicit.
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, the description carries the full burden and does reveal that spread_apr is gross carry before fees/slippage and that the Binance leg can be executed here. Yet it remains ambiguous whether this tool actually places orders or simply produces a signal, and it does not disclose potential side effects, permissions, or ordering 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 compact and front-loaded: the first sentence gives the core purpose, the second clarifies a metric caveat, and the third explains execution boundaries. Every sentence earns its place with no redundancy or filler.
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?
There is no output schema, so the description should explain return values. It mentions 'spread_apr' and 'best long/short venue pair' but does not describe the full output shape, how results are ordered, or what fields beyond spread_apr appear. The execution split is helpful, but the missing return details leave an agent with incomplete context 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 schema already documents all three parameters (base, min_oi_usd, min_spread_apr) with clear descriptions, so coverage is 100%. The description adds no additional parameter-level detail; the mention of 'spread_apr' refers to an output metric, not an input, so it does not enhance schema 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 identifies the tool as a delta-neutral funding-carry scan that picks the best long/short venue pair per asset by annualized funding spread. It is specific and uses a strong verb ('scan'), but it does not explicitly distinguish itself from the similarly named sibling chainvectorFundingArbitrage.
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 noting that spread_apr is gross carry before fees/slippage and that only the Binance leg can be executed here, while the perp leg needs a futures venue. However, it lacks explicit when-to-use/when-to-avoid guidance or alternatives, leaving the choice among the many chainvector strategy tools ambiguous.
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 must fully convey behavioral details, but it only states the data content (APR and exchange rates). It does not disclose pagination behavior, time-range interpretation, or any operational constraints beyond what is superficially evident. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose. It contains no filler or redundant phrasing, earning a maximum score for conciseness.
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 5-parameter read API with no output schema, the description gives a solid high-level overview but lacks details on response structure and operational semantics (e.g., how startTime/endTime affect the returned data). The schema compensates for parameters, but the description alone would not fully prepare an agent to interpret the results.
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 baseline is 3. The description does not add meaning beyond the schema; it only mentions the high-level output (APR, exchange rates) without linking to the size, current, or time parameters. The schema already documents each parameter 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 tool's function: retrieving historical BNSOL staking rate data including APR and SOL-to-BNSOL exchange rates. It uses a specific verb and resource, and is easily distinguished from sibling staking-related tools by naming the exact asset (BNSOL).
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 the tool is for BNSOL rate history queries but provides no explicit guidance on when to use it versus alternatives, no prerequisites, and no exclusion criteria. Sibling tools with similar purposes (e.g., BinanceGetWbethRateHistory) are not referenced, leaving selection to inference.
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 indicates a read-like operation ('Fetch') but does not disclose authentication requirements, response format, pagination, rate limits, or any side effects. This leaves significant behavioral ambiguity for a tool in the context of Binance API endpoints.
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 well-structured sentence that front-loads the verb and resource. It lists specific return details without extraneous words, making it concise 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?
For a simple no-parameter fetch tool, the description provides a reasonable overview by naming the resource and the fields returned (coin name, ID, algorithm name, algorithm ID). However, without annotations or an output schema, it omits contextual details like authentication requirements or whether the result is paginated, so it's not fully complete.
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 zero parameters, so the description has no parameter semantics to explain. Per the rubric, 0 params earns a baseline of 4. The description adds value by listing the output fields, which indirectly clarifies what the tool returns, but no parameter-specific details are needed.
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 uses a specific verb ('Fetch') and names the resource ('supported mining coins') and the key details returned (coin name, ID, algorithm name, algorithm ID). This clearly distinguishes it from sibling tools like BinanceAcquiringAlgorithm, which likely fetches algorithms instead of coins.
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 states what the tool does but provides no guidance on when to use it versus alternative mining-related tools. There is no mention of prerequisites, exclusions, or alternative tools to prefer in certain situations.
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?
Annotations are absent, so the description carries the burden. It states a safe read operation ('Retrieve') and mentions the output includes BTC/USDT equivalents, but it does not disclose authentication requirements, rate limits, or potential error/empty states. For a straightforward read, the transparency is adequate but not detailed, hence a mid-range score.
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 sentence that is concise and front-loaded with the action and result. It omits unnecessary details while covering the core purpose and output, earning full marks for conciseness.
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 simple read tool with one optional parameter, the description is mostly complete: it states what is retrieved and the output units. However, given similar sibling tools, a brief note distinguishing account balances from positions would have made it fully complete. It does not overpromise or miss critical info for its simplicity.
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 already documents the sole parameter 'recvWindow' with a complete description (time window, max 60000). With schema description coverage at 100%, the baseline is 3, and the description adds no extra parameter semantics. The simple optional parameter makes this sufficient.
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 'Retrieve' and the resource 'Dual Investment account balances', specifying what is returned ('total value in BTC and USDT equivalents'). It is distinct from sibling tools like BinanceGetDualInvestmentPositions, which target positions rather than 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 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 exclusions, prerequisites, or contrast with similar Dual Investment tools such as BinanceGetDualInvestmentPositions or BinanceGetDualInvestmentProductList. A simple read operation implies usage but there is no 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?
With no annotations, the description carries the sole burden of behavioral disclosure. The verb 'Retrieve' implies a read-only operation, which is a form of transparency, but it does not disclose any further behavioral traits such as rate limits, authentication needs, response structure, or side effects. It is minimally transparent but not rich.
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, concise sentence that is front-loaded with the key information. Every word contributes to clarity, and there is no filler or redundant phrasing.
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?
The tool is simple with one optional parameter and no output schema, so the description's mention of 'decimal precision (fraction) information for each supported asset' gives a reasonable expectation of the return concept. However, it lacks any detail about the response format or usage context, which prevents 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 coverage is 100% because the only parameter (recvWindow) is fully described in the schema. The description adds no parameter-specific information, but the baseline of 3 applies when the schema already documents parameters sufficiently.
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 uses a specific verb ('Retrieve') and a specific resource ('decimal precision (fraction) information for each supported asset in the Convert feature'), clearly distinguishing this tool from sibling Convert tools. It states exactly 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 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, nor does it mention any prerequisites or exclusions. It simply states the action without context, leaving the agent to infer usage from 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 must carry the burden of behavioral disclosure. It indicates the order must be active, but does not disclose side effects (e.g., permanence), required permissions, rate limits, or response behavior. This is a significant gap for a mutating 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?
One concise sentence that is front-loaded with the action and scope. No unnecessary words or repetition of the tool name. It is appropriately sized for a simple cancel operation.
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 does not explain return values, error cases, required permissions, or confirm that the order is canceled immediately. For a mutation tool, this lacks crucial 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%, with both 'algoId' and 'recvWindow' having descriptions. The tool description adds no parameter-level detail beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels an active algorithmic order on USDⓈ-M Contracts in Binance Futures. The verb 'cancel' and resource 'active algorithmic order' are specific, and the USDⓈ-M scope distinguishes it from spot algo order tools like BinanceSpotCancelOpenTWAPOrder.
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 gives clear context: it is for canceling active algo orders specifically on USDⓈ-M Futures, implying use when an algo order needs to be removed. It doesn't explicitly mention alternatives or exclusions, but the scope differentiates it from spot order cancellation tools. This is clear but not fully explicit.
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 must disclose behavior, but it only states 'retrieves', indicating read-only intent. It omits pagination behavior, response format, or constraints such as requiring an existing algoId, adding little beyond the purpose statement.
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?
A single front-loaded sentence with no filler. It efficiently conveys action, resource, scope, and context, and every word 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 simple parameterized read with a fully documented schema, the description provides sufficient selection context (futures sub-orders by algoId). It lacks prose on pagination and return shape, but the schema covers invocation parameters and the description clearly states what is returned.
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 per-parameter descriptions, so a baseline of 3 applies. The description adds futures scope and links sub-orders to algoId, but does not enrich page/pageSize/recvWindow beyond 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 uses the specific verb 'retrieves' with a clear resource ('sub-orders associated with a specified algoId') and scope ('USDⓈ-M Contracts in Binance Futures'). This distinguishes it from BinanceSpotSubOrders and algo-order-level tools like BinanceFutureHistoricalAlgoOrder.
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: pass an algoId to fetch its sub-orders. However, it provides no explicit when-to-use or when-not-to-use guidance and does not compare with alternative tools like BinanceSpotSubOrders or BinanceFutureCurrentAlgoOpenOrders.
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 burden of disclosing behavioral traits. It indicates a read-only operation via 'Retrieves information,' but does not add context such as default behavior when no collateralCoin is specified, pagination, or any potential side effects. The description is safe but lacks depth beyond the verb.
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 that are concise and front-loaded. The first sentence states the core function, and the second adds relevant context about the purpose of the ratios. There is no unnecessary repetition or filler.
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 simplicity of the tool (2 optional params, no output schema, no annotations), the description provides sufficient context for selection and invocation. It explains what the tool returns and why it matters. It doesn't describe edge cases like omitting collateralCoin, but the schema covers the parameters, and the description is complete enough for a read-only data retrieval 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 input schema already provides full descriptions for both optional parameters (recvWindow and collateralCoin), so the description does not need to add parameter-level details. The tool description itself adds no additional semantics beyond what the schema covers, so the baseline of 3 applies.
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 function with a specific verb and resource: 'Retrieves information about collateral assets, including collateral ratios and range values for different tiers of collateral.' This distinguishes it from sibling tools like BinanceGetLoanableAssetsData or BinanceGetBorrowInterestRate, even though it doesn't explicitly name them.
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 explicit guidance on when to use this tool versus alternatives. It mentions that ratios are 'used to determine the collateral requirement for various levels of borrowing,' which implies a use case, but this is not a clear directive or comparison with other 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 the full burden of behavioral disclosure. The verb 'Fetch' implies read-only, but it does not explicitly confirm that no side effects occur, nor does it mention authentication requirements, pagination behavior, or that holdings are account-specific. Lacks detail 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?
Single sentence, front-loaded with the primary action and resource, and lists three key output aspects. No redundant or fluff content; highly 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 straightforward read-only tool with schema-covered optional parameters and no output schema, the description is mostly complete. It names the key return fields and implies the scope. However, it could explicitly state that it is a read-only operation or require authentication, so it falls just short of a 5.
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 all 5 parameters, each with helpful notes like 'Page size' and 'Product ID (optional)'. The description adds no extra parameter context, so 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?
Description uses specific verb 'Fetch' with a clear resource: 'current holdings in Simple Earn Flexible Products', and explicitly lists what's included (total amount, reward rates, redeem status). This clearly distinguishes from sibling tools like BinanceSimpleEarnFlexibleProductList (which likely lists available products) and subscribe/redeem tools.
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 current positions but does not explicitly state when to use this tool versus alternatives (e.g., BinanceSubscribeFlexibleProduct for subscribing, BinanceRedeemFlexibleProduct for redeeming). No exclusions or alternative tools are mentioned, so guidance is only implicit.
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 burden of behavioral disclosure. It usefully states that the borrow limit is expressed in USD and that querying all assets is possible. However, it does not describe the return format, pagination, authentication needs, or rate limits. This adds some context but is not deeply transparent about the tool's full 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 two sentences long, with the main purpose front-loaded and the optional filtering behavior stated concisely. Every sentence contributes useful information without redundancy or filler.
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 query tool with three optional parameters and no output schema, the description covers the essential aspects: what it retrieves, the USD denomination of limits, and the filtering option. It does not describe the response structure, but given the schema fully documents the parameters and this is a simple data retrieval, the description is sufficiently complete. It slightly misses potential nuances like VIP level impact, but the schema captures the default behavior.
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 coverage is 100% with each parameter described in the input schema. The description adds a meaningful note about leaving the asset field empty to query all available assets, which clarifies the loanCoin parameter. However, it does not elaborate further on the meaning or expected values of vipLevel or recvWindow beyond what the schema already provides. Baseline 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 uses a specific verb 'Retrieves' and clearly identifies the resource: 'interest rates and borrowing limits for loanable assets.' It also notes the borrow limit is in USD and offers filtering, which helps clarify scope. However, it does not explicitly distinguish itself from related sibling tools like BinanceGetBorrowInterestRate, though the resource name 'loanable assets' is fairly unique.
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: use this tool to fetch loanable asset data, optionally filtered by specific assets. It does not explicitly state when to use it instead of alternatives, nor does it mention any exclusions or prerequisites. The guidance 'leave it empty to query all available assets' gives some context for when to use the optional parameter, but no broader selection guidance 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 of behavioral disclosure. It states 'retrieves' which implies a read-only operation, but it does not mention pagination behavior, time range handling, rate limits, required permissions, or any side effects. The description is thin on behavioral 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 consists of two concise sentences that are front-loaded with the primary action and then detail the return contents. Every sentence contributes useful information with no redundancy or 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 output schema, the description includes valuable return attributes (NFT network, token IDs, contract addresses, times, amounts, currencies). However, it omits behavioral context like pagination defaults or time range filtering, which are only in the schema. For a moderately complex tool, it is sufficiently complete but could mention date filtering or pagination behavior.
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 baseline is 3. The description lists the types of orders (matching the orderType parameter) and return attributes, but it doesn't add detail beyond what the schema already provides for parameters. It reinforces the meaning of orderType but doesn't compensate for any missing schema information.
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 retrieves NFT transaction history and enumerates specific transaction types (purchase, sale, royalty, primary market, mint fees). It differentiates from sibling NFT tools like deposit/withdraw history by focusing on trade-related history. The verb 'retrieves' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing the transaction types covered, but it does not explicitly state when to use this tool versus alternatives such as BinanceGetNFTDepositHistory or BinanceGetNFTWithdrawHistory. No exclusions or alternative references are provided, so usage guidance is implicit rather than explicit.
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?
Since no annotations are provided, the description carries the transparency burden. It discloses the types of data returned (asset conversion details, exchange rates, transaction status), which adds value. However, it does not cover pagination behavior, response structure, or any prerequisites or side effects. For a read-only 'Get' tool this is acceptable but leaves 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 a single, focused sentence that conveys the tool's purpose and key output details. It is efficient, though it could be slightly more concise by omitting unnecessary phrases like 'API allows users to'.
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 straightforward paginated history tool with no required parameters, the description is adequate but not rich. It doesn't explain default behavior, how the unwrap history relates to wrap or rewards history, or whether there are any limitations. The presence of an output schema could have helped but is absent.
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 each parameter already described (size, current, startTime, endTime, recvWindow). The tool description does not add any additional parameter-specific context beyond the schema, so the baseline 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 a specific verb ('retrieve') and resource ('historical records of WBETH unwrap operations'), and identifies the key output fields (asset conversion details, exchange rates, transaction status). It effectively distinguishes this from sibling tools like BinanceGetWbethWrapHistory, BinanceGetWbethRewardsHistory, and BinanceGetEthRedemptionHistory by explicitly naming 'Unwrap History'.
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 this tool is for retrieving WBETH unwrap history, but it doesn't provide explicit when-to-use guidance or mention any alternatives. Sibling tools (e.g., BinanceGetWbethWrapHistory) are not referenced, so the agent must infer from 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.
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 for behavioral disclosure. It communicates that the tool returns specific fields and supports pagination, which is useful. However, it does not explicitly state that it is a read-only operation, mention any required permissions, or describe edge cases or response format details beyond the listed fields.
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, front-loaded with the primary purpose, and contains no redundant or filler text. It efficiently conveys the tool's function and key details.
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?
The description adequately covers the tool's purpose and lists key output fields, which is important given there is no output schema. It also mentions pagination for large datasets. It does not mention the required 'algo' parameter or explicit auth prerequisites, but the schema handles parameter syntax. Overall, it is mostly complete for a straightforward 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?
Schema description coverage is 100%, so the schema fully documents all six parameters with descriptions. The description adds context about pagination and output fields but does not elaborate on parameter syntax or formats beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Retrieves the earnings associated with a mining account' and lists specific fields (earnings type, sub-account ID, mining account name, amount earned), giving a specific verb+resource. It does not explicitly differentiate from sibling tools like BinanceEarningsList, but the focus on mining account earnings provides reasonable 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 mining account earnings, but provides no explicit when-to-use guidance or exclusions relative to alternative earnings-related tools. There is no mention of prerequisites or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for disclosing behavioral details. It only restates the tool's purpose without mentioning side effects, prerequisites, rate limits, or what happens if the key is expired. This is a minimal restatement of the tool's name and offers no additional 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 a single sentence that is direct and unambiguous. Every word earns its place, with no unnecessary filler or repetition.
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?
This is a simple tool with one parameter and no output schema, so a large description is not required. The description conveys the essential action clearly. However, it leaves out potentially useful context such as the need to call this periodically before the listen key expires, but given the simplicity, it is 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?
Schema coverage is 100% (the parameter has a description). The description adds little beyond the schema: 'Extend the validity' clarifies that the listenKey is the one being kept alive, but it does not provide richer semantics like format, length, or example values. Baseline 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 uses a specific verb ('Extend') and clearly identifies the resource ('user data stream listen key'), distinguishing it from sibling tools like BinanceNewUserDataStream (create) and BinanceDeleteUserDataStream (delete).
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 the tool should be used to keep a user data stream alive, but it does not explicitly state when to use it relative to alternatives or mention any preconditions (e.g., listen key must already exist). No exclusions or alternative references are 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions output details (amount, conversion ratio, arrival time) but omits critical operational traits such as whether redemption is irreversible, processing delays, fees, or required permissions. For a financial transaction, this is a significant transparency 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 a single sentence that is direct and efficient. It slightly redundantly begins with 'Redeem ETH API', but it is not verbose and the key information is front-loaded. No wasted 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?
For a tool with 3 parameters and no output schema, the description gives the core purpose and some output specifics (amount, ratio, arrival time). However, it lacks information about the redemption lifecycle, error scenarios, and side effects, which is especially important for a financial operation. It is adequate but not comprehensive.
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. The description adds marginal value by reinforcing that asset can be WBETH or BETH and tying it to ETH redemption, but it does not provide additional syntax or format details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (redeem), the resources (WBETH or BETH), and the outcome (ETH), distinguishing it from related tools like BinanceWrapBeth and BinanceSubscribeEthStaking. The verb 'redeem' is specific and the resource is well-defined.
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 the tool: when users want to redeem WBETH or BETH for ETH. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous. A slight deduction for not naming sibling alternatives when to use this vs. wrap/subscribe tools.
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, the description must carry the burden. 'Retrieve' clearly implies a read-only operation, and the listed output fields give an idea of the response. However, it does not explicitly state that no data is modified, or discuss permissions, rate limits, or error behavior—leaving some ambiguity.
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, well-structured sentence that leads with the action and resource, then packs in valuable specifics. Every phrase adds meaning with zero filler or 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?
Despite lacking an output schema, the description enumerates the key return values (hash rates, valid/invalid units, profit), giving the agent a clear expectation of results. It does not describe potential error scenarios or pagination, but for a read-only stats tool this is reasonably 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 coverage is 100%, so the parameters are already well-documented in the input schema. The description adds context about the 'specific account' and output metrics, but does not enrich the meaning of individual parameters beyond their schema definitions, so the baseline 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 opens with the specific verb 'Retrieve' and clearly identifies the resource: 'mining statistics for a specific account.' It enumerates exact metrics (hash rates, valid/invalid units, profit), which differentiates it from sibling tools like BinanceAccountList (just lists accounts) or BinanceMiningAccountEarning (focused on earnings).
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 the many mining-related sibling tools (e.g., BinanceHashRateResaleList, BinanceMiningAccountEarning). The description only states what it does without clarifying exclusions or alternative use cases.
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 exist, so description carries full burden. It discloses the core behavior (gradual execution over duration) and the intended benefit (minimizing market impact), but omits operational details such as order lifecycle, return payload, or permission requirements. This is more than a tautology but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that are front-loaded and free of filler. It efficiently conveys the tool's purpose and mechanism without unnecessary repetition.
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?
As a 9-parameter order placement tool with no output schema and no annotations, the description should explain expected return values, order lifecycle, and how it integrates with related cancel/query tools. The brief description covers the concept but not the operational context needed for an 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 input schema has 100% parameter coverage with detailed descriptions (e.g., duration range, quantity notional limits, positionSide hedge mode rules). The tool description adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies 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?
Description clearly states the tool places a TWAP order on USDⓈ-M Futures contracts, using specific verb 'place' and resource 'TWAP order'. It distinguishes from spot TWAP and other order types by specifying the product and the gradual execution mechanism.
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?
Description implies usage context by explaining that TWAP orders execute gradually over a duration to minimize market impact, which suggests when to use it. However, it does not explicitly compare to alternative algorithms like BinanceVolumeParticipationNewTrade or standard market orders, nor state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states the action and required inputs. It does not mention effects (e.g., creating a loan obligation), prerequisites, permissions beyond master account, rate/interest implications, or what the response contains. This is insufficient for a financial mutation 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?
Two short sentences with no fluff. The purpose is front-loaded, and the second sentence summarizes key inputs. Every word earns its place, aside from a minor double space.
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?
Despite the schema covering parameters, this is a complex financial operation with 8 parameters and no output schema or annotations. The description omits important context such as prerequisites (e.g., checking collateral account or interest rate), what happens after submission, and relationship to related tools. It is too minimal for the tool's 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 already documents all 8 parameters. The description adds minimal value by summarizing that users specify the coin, amount, and collateral details, which maps to existing schema fields. No additional parameter relationships or nuances are provided beyond the schema.
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 function: applying for a loan by pledging collateral, with the specific constraint of master account only. It uses a specific verb ('apply for a loan') and resource ('pledging collateral'), and distinguishes from sibling tools like BinanceVipLoanRepay and BinanceVipLoanRenew by focusing on borrowing.
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 usage context by noting 'master account only', which is an explicit restriction. However, it does not mention alternatives or when not to use this tool compared to related VIP loan tools, so it falls short of a perfect score.
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 only states the action and term options, but fails to disclose the effects of renewal (e.g., replacing the old loan, extending the term), reversibility, required permissions, or any side effects. This is insufficient for a mutation 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 a single sentence, front-loaded with the action and key constraints. It is concise with no redundant words, effectively communicating the 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 mutation tool with no annotations and no output schema, the description is too sparse. It does not mention prerequisites (e.g., having an ongoing VIP loan), success/failure behavior, or return values, leaving significant contextual gaps for the 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 baseline is 3. The description reinforces the loanTerm enum (30/60) and that orderId refers to an existing loan, adding marginal context beyond the schema but not significantly compensating for any gaps. It does not clarify recvWindow beyond the schema 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 action ('renew'), the resource ('existing VIP loan'), and the scope ('specified term, either 30 or 60 days'). This distinguishes it from sibling tools like BinanceVipLoanBorrow and BinanceVipLoanRepay, 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 implies usage for existing VIP loans with a term of 30 or 60 days, providing clear context for the intended scenario. However, it does not explicitly exclude alternatives or state prerequisites such as having an ongoing loan order, so it falls short of full explicit guidance.
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 only mentions 'initiate' and 'travel rule compliance' without disclosing the mutating nature, consequences (e.g., irreversible fund transfer), required permissions, or return value. This is a significant gap 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 a single, front-loaded sentence that captures the core action and differentiator. It wastes no words and is appropriately sized for the information it conveys.
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?
Despite having 12 parameters, 8 required, and no output schema, the description is minimal. It does not explain what the tool returns, the compliance workflow, or how it relates to sibling withdrawal tools. The high complexity and lack of annotations demand more context than this one-liner provides.
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 covers all 12 parameters with descriptions, so the baseline is 3. The tool description adds no extra semantic meaning beyond the schema; it references 'broker withdrawal' but does not explain how parameters like subAccountId or originatorPii relate to the broker context.
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 uses a specific verb ('Initiate') and resource ('broker withdrawal') and adds a distinguishing qualifier ('with travel rule compliance'). This clearly differentiates the tool from sibling tools like BinanceWalletWithdraw and BinanceWalletWithdrawTravelRule by scoping it to broker withdrawals.
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 implies the tool is for broker withdrawals, which provides clear context for when to use it. However, it does not explicitly state when not to use it or name alternative tools, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the metric's definition, cross-exchange scope, and bucket aggregation, providing useful context. However, it does not describe the return shape, units, or any operational details like pagination or limits.
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 dense, information-rich sentences: the first defines the metric and scope, the second gives actionable interpretation. Every sentence earns its place with no filler.
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 simple tool with two optional parameters and no output schema, the description is largely complete: it defines the metric, explains its meaning, and signals when extremes are significant. Return-value structure is not detailed, but that is not critical for selecting and invoking this data-query 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 baseline is 3. The description's 'per bucket' aligns with the interval parameter but does not add meaningful new detail beyond what the schema already provides for symbol and interval.
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 identifies the specific metric (long/short taker ratio per bucket, cross-exchange) and distinguishes it from other chainvector tools. It lacks an explicit verb like 'returns' or 'fetches', so it falls just short of 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?
It gives interpretive context ('Extremes flag one-sided positioning that squeezes easily') that implies when the metric is valuable, but it does not explicitly state when to prefer this tool over similar chainvector metrics or mention alternatives. Usage is implied rather than directly stated.
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 transparency burden. It indicates a read-only operation through 'retrieve' and lists the data fields, but does not explicitly state side-effect-free behavior, authentication needs, or error conditions. For a simple get, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but somewhat redundant, repeating the tool name in 'Get SOL Staking Quota API allows users to retrieve'. It could be more concise, but it is not overly verbose.
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 (one optional parameter, no output schema), the description provides useful context by enumerating the returned data (limits, minimums, fees, availability). It lacks usage scenarios or exclusions but is largely complete for a simple retrieval 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 single parameter recvWindow is fully described in the schema (100% coverage), so the description adds no additional meaning. The baseline of 3 applies because 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 tool retrieves the user's current SOL staking quota and lists specific data included (remaining limits, minimum amounts, fees, availability). This distinguishes it from staking account or history tools, 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 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 it (when needing SOL staking quota details) but lacks explicit exclusions or comparisons to sibling staking tools. The description is sufficient for an agent to understand the general use case.
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 important behavioral logic (loan vs collateral account returns different sets of accounts), but does not mention authentication requirements, rate limits, or the read-only nature explicitly. The word 'check' implies a safe query, but more transparency about access prerequisites would be beneficial.
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, two sentences, front-loaded with the primary purpose, and every sentence adds value. No filler or repetition.
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?
The main behavior is explained clearly, including the conditional account-type logic. However, the three optional parameters are not integrated into the description, and there is no output schema to clarify return structure. For a query tool of this complexity, the description is adequate but leaves room for ambiguity regarding param usage and return specifics.
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 baseline is 3. Each parameter has only a minimal 'Optional' label, and the description adds no extra meaning about how orderId or collateralAccountId affect the results, so it does not compensate beyond the schema.
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 allows users to check collateral accounts and the coins held as collateral, with a specific verb ('check') and resource. It also explains the conditional behavior based on account type, which distinguishes it from sibling tools like BinanceGetVIPLoanOngoingOrders and BinanceGetCollateralAssetData.
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 querying collateral accounts by describing the account-type-dependent behavior, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. The guidance is thus implied rather than explicit.
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 burden of behavioral disclosure. It states the return content (estimated rewards, holding amounts, APR) but does not discuss pagination, time range handling, or any API-specific quirks. It adequately conveys that this is a read operation, but could provide more detail on response behavior.
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 sentence that efficiently communicates the tool's purpose and key data fields. It is wordy with 'allows users to retrieve' but contains no unnecessary information. Front-loaded and easy to read.
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 output schema, the description appropriately summarizes what the tool returns (estimated rewards, holding amounts, APR). It does not delve into response structure or edge cases, but for a straightforward historical data query, it provides a sufficient context. The sibling tools are numerous, but the description gives enough to differentiate this tool's specific focus.
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 parameters (size, current, endTime, startTime, recvWindow) are already well-documented. The description adds no additional parameter semantics beyond the schema, making the baseline score of 3 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 tool's function: retrieve historical reward data from WBETH holdings, including estimated rewards, holding amounts, and APR. This distinguishes it from sibling tools like BinanceGetWbethRateHistory or BinanceGetWbethWrapHistory, which cover different aspects of WBETH.
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 the use case (obtaining historical WBETH reward data) but does not explicitly mention when to prefer this over alternatives. It lacks exclusion criteria or comparisons with sibling tools, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclose a key behavior: omitting the symbol returns all symbols. However, it does not mention response format (e.g., single object vs. map), or any other operational details. Given the simplicity of a read-only price lookup, this is minimal but acceptable.
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, tightly worded sentence that conveys the action, resource, and scope without any filler. It is appropriately sized and front-loaded, making it highly 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?
The tool is simple and the schema covers the parameter, but the description lacks usage context and differentiation among many sibling ticker tools. It is sufficient for a basic lookup but does not explain what 'all symbols' returns or how to interpret the output, especially in absence of an output schema. This leaves moderate ambiguity for the 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 schema covers the 'symbol' parameter with a description and optionality, but the description adds the crucial behavioral nuance that omitting the symbol yields all symbols. This goes beyond the schema's explicit statements and clarifies the parameter's optional usage, providing added semantic 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 uses a specific verb 'Get' and a clear resource 'latest price' with an explicit scope: 'for a symbol or all symbols.' This distinguishes it from sibling ticker tools like BinanceTicker24hr or BinanceTickerBookTicker, which serve different data. The purpose is unambiguous and actionable.
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 other ticker tools such as BinanceTicker24hr, BinanceTickerBookTicker, or BinanceTickerTradingDay. It does not mention scenarios, prerequisites, or alternatives, leaving the agent to infer usage context from 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, the description must disclose side effects, but it only states the action and return values. It does not mention that this is a transaction that will debit BETH from the account, require a BETH balance, or have any fees/prerequisites. The word 'convert' implies a write but lacks explicit disclosure of behavioral impact.
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 concise sentence that front-loads the purpose ('Wrap BETH API') and includes the key output details. No redundant words or filler, making it easy 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?
The tool is a simple conversion operation with no output schema, and the description does mention the response includes the wrapped amount and exchange rate. However, it omits important context like prerequisites (BETH balance), potential fees, or how the exchange rate is set. Given the lack of annotations, this leaves some gaps for a financial 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 coverage is 100%, with 'amount' and 'recvWindow' already described. The description adds no additional parameter-level meaning beyond reiterating the conversion context. Since the schema handles parameter documentation, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'convert BETH into WBETH' with a specific verb and resource, and mentions the result (wrapped WBETH amount and exchange rate). It distinguishes from sibling tools like BinanceGetWbethWrapHistory and BinanceRedeemEth, which handle history and unwrapping 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 clear context: this tool is for wrapping BETH into WBETH. It implies when to use it, but does not explicitly mention alternatives or exclusions. The sibling names are self-explanatory, reducing the need for explicit exclusion notes.
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, the description must carry the behavioral disclosure burden. It explains the calculation logic and output scale (0-100, direction), which is useful, but it does not disclose data source, return structure, or limitations. It adds interpretive value but leaves out practical behavioral details.
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 long, front-loaded with the core definition and followed by an interpretive note. Every sentence earns its place with no filler.
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?
In the absence of an output schema, the description gives a high-level summary ('pressure_score 0-100 with direction buying/selling') but leaves ambiguity about whether the 1m/5m/15m windows produce separate scores or an aggregate. It also omits details like timestamps or symbol echoed in the response. The context is adequate for a simple metric tool but incomplete for clear 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 coverage is 100% with descriptions for both 'symbol' and 'min_notional'. The description reinforces 'min_notional' as a threshold ('>= min_notional USD') but adds no new meaning for 'symbol'. Since the schema already documents both parameters well, the description's contribution is marginal, so baseline 3 applies.
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 computes 'ChainVector whale pressure' from 'large-trade (>= min_notional USD) taker aggression over 1m/5m/15m windows' and outputs a 'pressure_score 0-100 with direction buying/selling'. This is a specific verb+resource definition that distinguishes it from other chainvector tools like chainvectorOrderflowCvd or chainvectorFundingWeighted.
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 line 'Whales leaning one way while price is flat often front-runs the move' hints at a use case, but it does not explicitly state when to choose this tool over alternatives or mention exclusions. It provides context but no direct usage guidance.
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, and the description only states the action without disclosing side effects, permission requirements, or consequences. As a mutation tool, this lacks important behavioral context such as whether the change is reversible or takes effect immediately.
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?
One sentence, no fluff, front-loaded with the verb and object, efficiently conveys the core purpose without wasting 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?
Adequate for a simple mutation tool but lacks behavioral transparency and usage exclusions. No output schema or annotations, yet the description does not clarify return values or operational impact, leaving some gaps for an 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?
All parameters are already fully described in the schema (100% coverage). The description reiterates the enum values and position ID usage but adds no additional semantic detail beyond what the schema provides, so baseline 3 applies.
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 (Change) and the resource (Auto-Compound plan for a Dual Investment position), explicitly lists the three allowed values (NONE, STANDARD, ADVANCED), and specifies the identification method (position ID). This distinguishes it from sibling read-only tools like BinanceGetDualInvestmentPositions.
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: whenever the auto-compound plan of a Dual Investment position must be modified. However, it does not explicitly mention alternatives or scenarios where this tool should not be used, so it falls short of a perfect 5.
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 states the action (canceling an order) and that it returns status, but it does not disclose details such as irreversibility, potential errors (e.g., order not found), or whether partial fills can be canceled. The mention of 'previously placed' gives some context, but the behavioral profile is minimal.
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 sentence that clearly states the action and return value. It is front-loaded with the verb and resource, contains no redundant words, and is immediately understandable.
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 simple cancel operation with two well-documented parameters and no output schema, the description provides sufficient context. It states what is canceled and what is returned, though it could further clarify prerequisites (e.g., order must be in a cancellable state) or error handling, but these are not critical for basic 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?
The schema provides 100% coverage for both parameters: orderId is described as 'The orderId from placeOrder API' and recvWindow as 'Time window for request validity'. The description adds no further meaning beyond the schema, satisfying the baseline for high coverage but not exceeding it.
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 states a specific action ('Cancels'), a specific resource ('previously placed limit order'), and the method ('using the orderId'). It also mentions the return value ('cancellation status along with the orderId'). This clearly differentiates it from sibling cancel tools like BinanceDeleteOrder, which targets spot orders, while this targets Binance Convert limit 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 it is used for limit orders placed via Binance Convert, but it does not explicitly state when to use this tool versus alternatives like BinanceDeleteOrder or BinanceSpotCancelOpenTWAPOrder. No exclusions or alternative tools are mentioned, leaving the agent to infer the appropriate context from the tool name and description.
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 correctly indicates a read-only query (using 'Query') and discloses the primary output (min/max amounts for source and destination). However, it does not mention behavior when no parameters are supplied, pagination, or any authentication requirements. This is acceptable for a simple read tool but lacks richer 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, well-structured sentence that immediately states the action and the key output. Every part adds value, with no fluff or repetition. It is front-loaded with the primary purpose.
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 simple query tool with two optional parameters and no output schema, the description covers the core functionality and main output. It does not explicitly explain filtering behavior when both parameters are provided, but this is easily inferred. Given the low complexity, it is fairly 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 both fromAsset and toAsset having clear descriptions ('User spends coin' / 'User receives coin'). The tool description adds the context of 'source and destination tokens' but does not provide additional syntax or format details. Baseline of 3 is appropriate since the schema already documents the parameters well.
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 uses a specific verb ('Query') and identifies the resource ('available conversion pairs') with an example (BTC to USDT). It also states the key output (min/max amounts for both tokens), clearly distinguishing it from sibling convert tools like quote requests or order management.
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 usage is implied: this tool is for discovering available conversion pairs and their amount limits. However, it does not explicitly state when to use it versus alternatives, such as before placing a convert order or in contrast to other convert-related tools. No exclusions or alternative tool names are provided.
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, the description carries full responsibility. It implies a read-only operation and lists the return fields (conversion status, assets, amounts, exchange rate, creation time), but it does not explicitly disclose side effects (or their absence), error conditions, or any constraints beyond the parameter mutual exclusivity.
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, focused sentence, front-loaded with the verb and resource, and includes a concise enumeration of the key return fields. No unnecessary words or repetition.
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 simple status-check tool with two parameters and no output schema, the description adequately covers purpose, parameter relationship (via schema), and return values. It does not mention how to obtain an orderId/quoteId or handle errors, but those are not essential for correct 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 coverage is 100% and each parameter already states 'either this or the other is required'. The description merely repeats the 'either orderId or quoteId' relationship without adding new meaning, so it adds no value beyond the structured parameter data.
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 specifies the exact action ('checks the status') and resource ('token conversion order'), and clarifies it uses orderId or quoteId. This clearly distinguishes it from sibling tools like BinanceGetOrder (for regular orders) and other BinanceConvert tools for creating or accepting quotes.
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?
Usage context is implied ('checks status of a conversion order'), but the description does not explicitly state when to use this tool versus alternatives like BinanceGetOrder, nor does it mention any exclusions or prerequisites. The 'when-to-use' guidance is minimal.
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, the description must carry the full burden. It discloses the destructive action and exact scope ('all open orders'), but does not mention irreversibility, permissions, rate limits, or return format. The verb 'Cancel' implies mutation, and the description clarifies exactly what is affected.
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?
One concise sentence that is action-first and free of redundant wording. It conveys the tool's purpose and scope with minimal 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 simple one-parameter cancel-all tool, the description sufficiently explains the core operation. However, it does not specify the response format or mention edge cases (e.g., when there are no open orders), but these are minor gaps given the tool's simplicity.
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 coverage is 100%, and the schema already provides a clear description of the 'symbol' parameter with an example ('BTCUSDT'). The description's 'specific symbol' adds no extra semantic value beyond what the schema already provides.
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 a specific verb ('Cancel') and resource ('all open orders on Binance') with a clear scope ('for a specific symbol'). It distinguishes from siblings like BinanceDeleteOrder (single order) and BinanceGetOpenOrders (read-only).
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 intended use is implied: use this tool to cancel all open orders for a symbol. However, it does not explicitly mention when to prefer this over BinanceDeleteOrder or other alternatives, and it lacks exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the core behavior (invalidating the listen key) but does not state consequences such as the stream no longer delivering updates or whether the action is irreversible. For a delete-like operation, this is minimal but not misleading.
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 is front-loaded with the action and resource, making it 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?
For a simple one-parameter delete stream tool with no output schema, the description covers the essential behavior. It could mention the relationship to the other user data stream tools, but it is adequately complete for the operation's simplicity.
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 'listenKey'. The description adds the context 'by invalidating the listen key' but this essentially restates the schema's 'Listen key to close' without providing new meaning, so it stays at baseline 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 uses a specific verb 'Close' and clearly identifies the resource 'user data stream' with the mechanism 'by invalidating the listen key'. This distinguishes it from siblings like BinanceNewUserDataStream (create) and BinancePutUserDataStream (keep-alive).
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 usage is implied by the action 'Close' but there is no explicit when-to-use guidance or mention of alternatives. It does not state 'use this when you no longer need updates' or compare with BinancePutUserDataStream, so the guidance is not fully fleshed out.
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 uses the read-only verb 'retrieve' and adds useful context about including WBETH and BETH amounts, but does not explicitly disclose auth requirements, rate limits, or that it is a read-only operation. It is not misleading but lacks depth.
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, focused sentence that is front-loaded with the tool's purpose. It contains no filler or redundant information, 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?
The tool is simple with one optional parameter and no output schema. The description clearly states what data is returned (current holdings, 30-day profit, WBETH/BETH amounts), providing a good high-level overview. However, it does not detail the response structure or explicitly confirm read-only status, leaving minor 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 only parameter (recvWindow) is already fully described in the schema with 100% coverage. The description adds no additional meaning about the parameter, so the schema carries the entire semantic load. Baseline of 3 applies.
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 uses the specific verb 'retrieve' and names the resource (ETH staking holdings and 30-day profit details) including specific asset types (WBETH and BETH). This clearly distinguishes it from sibling tools like BinanceGetCurrentEthStakingQuota or BinanceGetEthRedemptionHistory.
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 staking account holdings and profit, but does not explicitly state when to use this tool vs alternatives or exclude other scenarios. No alternatives or when-not-to-use guidance is provided, leaving usage largely inferred.
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 that the tool returns daily and yearly rates and supports multiple assets, which is useful. However, it does not mention response format, authentication, rate limits, or error behavior, leaving gaps in transparency for a read operation.
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, front-loaded with the primary purpose, and contains no redundant or filler content. Every sentence adds relevant 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?
For a simple tool with two parameters and no output schema, the description covers the core purpose, return content (daily/yearly rates), and input format. It lacks a detailed response structure and omits the optional recvWindow parameter, but given the tool's simplicity, the description is reasonably 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% for both parameters, so the baseline is 3. The description adds example assets (BUSD, BTC) but mostly reiterates the comma-separated list and asset limit already in the schema. It does not add significant new meaning beyond what the schema provides.
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 retrieves borrowing interest rates, mentioning both daily and yearly rates for multiple assets. This distinguishes it from sibling tools, none of which cover borrow interest rate retrieval. The verb 'Retrieves' plus explicit resource makes 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need borrowing interest rates and gives input formatting guidance (comma-separated list), but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. This is clear context but lacks explicit alternative 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, the description carries the transparency burden. It accurately discloses the read-only nature ('Fetch') and mentions batch behavior, filtering, and pagination, which are useful behavioral traits. However, it omits details like authentication requirements, potential errors, rate limits, or return format specifics, which would be valuable given the absence of 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 two sentences long, front-loaded with the core action and resource, followed by a concise mention of filtering and pagination. Every word contributes to understanding the tool's function, with no redundancy or filler.
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 output schema, the description provides a reasonable outline of what the tool returns (status, subscription details, APR, settlement info) and how to refine results. All parameters are documented in the schema, so the description covers the main functional aspects. It could be more complete by mentioning defaults (e.g., page size) or edge cases, but for a straightforward read tool it is largely sufficient.
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 coverage is 100% with each parameter already described in detail. The description adds only a high-level summary ('Filter by status or paginate results') that maps directly to the schema parameters. It does not provide additional semantic nuances beyond what the schema already offers, so 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 uses a specific verb ('Fetch') and clearly identifies the resource ('Dual Investment positions'), while detailing what is included (status, subscription details, APR, settlement info). It distinguishes this from sibling tools by focusing on positions and adding filter/pagination capabilities, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 and pagination, but it does not explicitly contrast with sibling tools like BinanceGetDualInvestmentProductList or BinanceSubscribeDualInvestmentProducts. No exclusions or when-not-to-use guidance is provided, leaving the agent to infer context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The word 'Retrieve' and the phrase 'to view details' convey that this is a read-only operation, which is useful given the absence of annotations. However, the description does not disclose other behavioral traits such as pagination behavior, potential empty results, authentication requirements, or any rate-limit considerations, leaving the agent without a full behavioral picture.
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, tightly written sentence that front-loads the core action and directly includes the main filtering and output concepts. There is no redundant or unnecessary wording, making it easy 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 that there is no output schema and no annotations, the description does a reasonable job of explaining what the tool returns (APR, strike price, duration, purchase availability) and how the inputs relate. It could be more complete by explicitly stating the response is a paginated list or by pointing to related tools, but the essential information for selection and invocation is present.
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 already provides descriptions for all six parameters, so the baseline is 3. The description adds some context by stating that invest and exercised coins are used to filter products and that the output includes APR, strike price, duration, and purchase availability, but it does not add meaningful syntax or format details beyond the schema.
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 uses a specific verb ('Retrieve') and identifies the exact resource ('available Dual Investment products'), plus the key filtering dimensions (option type, invest coin, exercised coin). It clearly differentiates from sibling tools like BinanceGetDualInvestmentPositions by focusing on available products rather than user positions.
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 clearly implies when to use the tool (when you need to browse available Dual Investments for given coins and option type), but it provides no explicit guidance about when not to use it or how it relates to alternatives like subscribing or checking positions. The context is understandable but lacks exclusions or alternative references.
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 fetching history but does not disclose pagination behavior, time range constraints, or that this is a read-only operation. Since this is a data retrieval tool, stating that it returns paginated results (matching the page/rows params) would add necessary context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose and output details without any wasted words. It is front-loaded with the primary action and resource.
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?
The tool is relatively simple, and the schema clearly documents all 6 parameters. The description covers the output fields, which helps since there is no output schema. However, it does not mention pagination or time filtering behavior, which are relevant for a history retrieval tool. Despite this gap, the overall information is sufficient for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by listing the types of transaction details returned, which helps the agent anticipate output, but it does not elaborate on the transactionType parameter values (0/1) or the time range parameters beyond what the schema already provides. This is acceptable since the schema descriptions are thorough.
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 fetches fiat deposit or withdrawal history and lists the key transaction details (amount, currency, method, status, timestamps). This distinguishes it from sibling tools like BinanceWalletDepositHistory (crypto) and BinanceGetFiatPaymentsHistory (fiat payments).
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 that this tool is for fiat deposit or withdrawal history, making it obvious when to use it for fiat-related historical queries. However, it doesn't explicitly state when not to use it or mention alternatives, which would be helpful given the many sibling history 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, the description must disclose behavioral traits on its own, but it only states that the tool 'checks and returns' data. It does not mention authentication requirements, rate limits, error conditions, or explicitly confirm that this is a read-only operation. The timestamp mention is helpful but insufficient to fully describe 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, well-structured sentence that immediately states the tool's purpose and key output. Every word earns its place, and there is no fluff or redundant 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?
For a simple one-parameter read-only status check with no output schema, the description adequately covers what is returned (lead trader status and timestamp). It could be more complete by mentioning authentication prerequisites or potential errors, but given the tool's low complexity, it is largely sufficient.
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 coverage is 100% for the single optional parameter (recvWindow), and the schema already describes it as 'Optional time window for request validity'. The description adds no additional parameter semantics, 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 uses a specific verb ('Checks and returns') and clearly identifies the resource: whether the user is currently a Futures Lead Trader in Binance Copy Trading. It also mentions the timestamp of the status check, distinguishing this from the related sibling tool BinanceGetFuturesLeadTradingSymbolWhitelist.
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 makes the tool's use case clear: determine if the user is currently a Futures Lead Trader. While it doesn't explicitly mention alternatives or when not to use it, the context is unambiguous and no competing sibling tool serves this exact purpose.
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 burden. It describes the returned data but does not explicitly state that this is a read-only operation or mention any side effects, authentication, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It efficiently conveys the essential 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?
Without an output schema, the description provides useful detail about the response content (whitelist symbols including base and quote assets). However, it doesn't specify the exact response structure or formatting, which would be 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 only parameter recvWindow is fully described in the schema, so the description adds no additional semantics. Baseline 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 identifies the tool's purpose as providing the whitelist of trading pairs allowed for Futures Lead Traders in copy trading. It distinguishes from sibling tools like BinanceGetFuturesLeadTraderStatus by specifying the whitelist content including base and quote 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 in the context of Futures Lead Traders copy trading but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. No sibling tools are directly compared.
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?
Without annotations, the description carries the full burden. The verb 'Retrieve' strongly implies a read-only operation, but it does not explicitly state side-effect freedom, authentication requirements, or any other behavioral detail. It adds little beyond the obvious, leaving some ambiguity about the operation's safety profile.
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, front-loaded with the action 'Retrieve NFT assets', and every sentence adds value. It mentions the return details in the second sentence without fluff or 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?
Despite lacking an output schema and annotations, the description sufficiently explains the tool's purpose and return fields for a simple list operation. The optional parameters are clearly documented in the schema, and the description covers the core functionality. Some minor gaps like authentication context remain, but overall it is reasonably 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 schema already provides 100% description coverage for all three parameters (page, limit, recvWindow). The tool description adds no additional parameter semantics or usage details beyond what the schema states, so it is at 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 uses the specific verb 'Retrieve' to state it fetches NFT assets for a user's account, and lists concrete return details (network, contract address, token IDs). This clearly distinguishes it from sibling tools like NFT deposit/withdraw/transaction history, which focus on different aspects.
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 use when needing a user's NFT asset list, but does not explicitly mention when to avoid it or provide alternatives. There is no direct comparison with sibling tools. The context is present but not fully elaborated, so it earns a mid-tier 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 must carry the full burden. It mentions the returned fields (network, contract address, token ID, transaction ID, timestamps) but does not disclose authentication requirements, rate limits, or how the startTime/endTime parameters affect the query.
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, concise sentence that delivers essential information without wasted words. It clearly states the resource and key output fields.
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 output schema and no annotations, the description adequately covers the main purpose and return fields. It is missing minor details like default time range or pagination limits, but for a simple history-fetch tool, it is sufficiently 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% coverage, with descriptions for all 5 parameters. The tool description adds no extra semantic detail for the parameters beyond listing some response fields, 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 tool retrieves NFT deposit history, listing key return fields. It distinguishes from siblings like BinanceGetNFTWithdrawHistory and BinanceGetNFTTransactionHistory by specifying 'deposit'.
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 intended use is implied by the name and description but not explicitly stated. No guidance is provided on when to use this tool versus the sibling tools for withdrawals or transactions, nor any context on time ranges or pagination.
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, the description carries the full burden. 'Get' implies a read-only operation, and it clarifies that all symbols are returned if symbol is omitted. However, it does not disclose authentication needs, rate limits, pagination, or whether it covers only spot markets, which are relevant behavioral 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 sentence, front-loaded with the action, and contains no redundant information. Every word contributes to clarity.
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?
The tool is simple with one optional parameter and no output schema, so the description is mostly sufficient. It covers purpose and symbol behavior, but could be more complete by noting return format or clarifying the market type (spot vs futures) given the diverse Binance sibling tools.
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 already documents the 'symbol' parameter with an example, and the description adds the behavioral nuance that the parameter is optional and that omitting it returns all open orders. This adds meaning beyond the schema.
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 uses a specific verb ('Get') and resource ('all open orders') and clearly states the scope ('for a specific symbol or all symbols'). This distinguishes it from siblings like BinanceAllOrders and BinanceGetOrder by focusing on open orders.
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 does not mention when to use this tool versus alternatives such as BinanceOpenOrderList or BinanceAllOrders. It offers some guidance on the optional symbol parameter but no explicit context for tool selection or exclusions.
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 is for VIP users (permission context) and that it returns only active loan orders (behavioral filter). However, it does not mention pagination behavior, response format, or rate limits, leaving some gaps given the absence of 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 two sentences, front-loaded with the core purpose and followed by filter options. Every word earns its place; no fluff or 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 moderate complexity (7 optional parameters, no output schema, no annotations), the description adequately covers the core purpose and main filter capabilities. It does not explicitly describe return values, but 'retrieve a list' implies a list response. Some detail on pagination could be inferred from the schema, so the description is sufficiently complete, 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% parameter description coverage, so the baseline is 3. The description lists four filterable fields (loan coin, collateral coin, order ID, collateral account ID) but adds no meaning beyond their names; the schema already describes each parameter. It does not clarify pagination or recvWindow usage beyond what schema states.
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 identifies the tool's function: retrieving a list of active VIP loan orders. It uses a specific verb ('retrieve'), a resource ('current active loan orders'), and scope ('VIP users'), which distinguishes it from sibling tools like borrow, repay, and renew.
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—use this tool when you need to view active VIP loan orders. However, it does not explicitly state when not to use it or mention alternatives (e.g., historical orders or other loan status tools). The 'current active' wording gives some context but lacks exclusions.
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, the description carries the burden. 'Retrieve' implies a read-only operation, but it does not disclose pagination behavior, rate limits, or that results may vary by market conditions. It mentions return fields but no deeper behavioral 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, front-loaded sentence. It clearly states the action, object, and relevant return details without any unnecessary 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 simple read-only list tool with all parameters documented in the schema, this description is mostly complete. It would benefit from mentioning pagination explicitly, but the schema already includes size and current. The return fields are partially described, which helps.
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 baseline is 3. The description does not add meaning to the parameters (size, asset, current, recvWindow) beyond what the schema already provides, but it also does not need to compensate.
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 (Retrieve) and the resource (available Simple Earn Flexible Products), and it names the key returned details (APR, purchase status, subscription limits). This distinguishes it from sibling tools that subscribe, redeem, or query positions.
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?
Usage is implied: use this to browse available flexible products. However, there is no explicit guidance on when to prefer this over other list tools (e.g., dual investment product lists) or exclusions. No alternative tools are named.
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 clearly conveys that this is a read-only operation ('Get') and adds useful context about the rolling window nature and the ability to query all symbols. It does not discuss rate limits or error behavior, but for a simple read-only ticker endpoint, the description is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the essential behavior without any wasted words. It is grammatically clear and easily parsed by an 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?
For a tool with only two optional parameters and no output schema, the description is nearly complete: it states the resource type, the time window, and the symbol scope. Minor gaps include not specifying the exact return fields (e.g., that it returns detailed statistics like lastPrice, priceChangePercent) and not clarifying the default windowSize behavior beyond '24-hour', but these are not critical given the schema descriptions.
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 already provides 100% coverage for both parameters, so the baseline is 3. The description adds no additional meaning beyond what the schema already states, except implicitly confirming that the 'symbol' parameter can be omitted to return all symbols. This matches the schema's optionality but does not go further.
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 a specific verb ('Get') and resource ('24-hour rolling window price change statistics') with optional symbol scope. It is specific and actionable, but does not explicitly distinguish itself from closely related sibling tools like BinanceTicker24hr or BinanceTickerTradingDay, which likely share a similar purpose.
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 24-hour price change statistics are needed, and notes that it can be called for a single symbol or all symbols. However, it offers no explicit guidance on when to use this tool versus the many related ticker endpoints (e.g., BinanceTicker24hr, BinanceTickerPrice, BinanceTickerBookTicker), and provides no exclusions or alternative recommendations.
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, the description carries the full burden of behavioral disclosure. It does state the key behavioral effects: updating remaining principal and interest, and providing repayment status. However, it does not disclose potential side effects, permission requirements, reversibility, or any constraints beyond the schema. This adds some value but falls short of a fully transparent behavioral description.
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 long, with the main action front-loaded in the first sentence. Every phrase adds value: it specifies the target users (VIP), the action (repay), the scope (partial/full), and the result (updated principal/interest and status). There is no repetition or filler, making it concise 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 no output schema, the description does mention that the tool 'provides the repayment status', which gives some expectation of the return value. Combined with the clear purpose and effect, this is reasonably complete for a repayment action. However, it is somewhat vague about the exact status structure and lacks any error-handling or constraint details, so it is not a 5.
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 covers all parameters with descriptions (100% coverage), so the baseline is 3. The description does not add any additional meaning or detail about the parameters; it only refers to 'specified amount' without expanding on orderId or recvWindow. Since the schema already handles parameter semantics, the description provides no extra value here.
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: allowing VIP users to repay a specified amount of an active loan, partially or fully. It also describes the effect (updating remaining principal and interest) and the output (repayment status). This distinguishes it from sibling tools like BinanceVipLoanBorrow and BinanceVipLoanRenew, which handle different loan operations.
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 a VIP user wants to repay a loan, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. There is no guidance comparing it to related tools like borrow or renew, so the usage context is only implicit.
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 disclosure. It explains the output metric (basis in bps, annualized carry) and its interpretive meaning, but does not mention data limitations, update frequency, or response structure—leaving some ambiguity about what the consumer will receive.
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: the first sentence states the core purpose, the second provides interpretation, and the third notes a practical use case. Every sentence adds meaningful information with no filler.
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 simplicity (one optional parameter, no output schema), the description adequately explains the metric, venue-level scope, and interpretation. It could be more complete by noting the exact output shape or data source, but for this level of complexity it is sufficiently 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 schema covers 100% of parameters with a single 'base' parameter defaulting to BTC and described as 'Asset symbol, default BTC'. The description adds no additional parameter semantics, so the baseline score of 3 applies since the schema already fully documents the parameter.
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 identifies the tool as computing spot-perp basis per venue in bps with annualized carry, which is specific and distinguishes it from sibling chainvector tools like funding or momentum. However, it lacks an explicit verb such as 'retrieve' or 'calculate', making it slightly less direct than ideal.
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 interpretive guidance: persistent premium indicates leveraged longs crowding, discount indicates shorts, and it is the input for cash-and-carry trades. This gives strong context for when to use the tool, though it does not explicitly contrast it with alternative tools.
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 transparency burden. It explains the meaning of the scores and direction, which is useful, but it does not disclose whether it is a read-only operation, data freshness, or any other behavioral 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 two sentences that are direct and informative. It front-loads the tool's identity and includes the key output details and an interpretation hint, with no redundant 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?
Given the tool's simplicity (one parameter, no output schema), the description covers the main return fields and offers a practical interpretation. It could be more complete by listing all expected output fields or linking to related tools, but it is sufficient for a basic gauge.
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 coverage for the only parameter (symbol) is 100%, so the schema already fully documents the parameter. The description adds no additional parameter semantics, which aligns with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a 'funding-squeeze gauge' and specifies the key outputs (aggregate_score, crowded side, squeeze_direction). This distinguishes it from sibling tools like chainvectorFundingCurrent or chainvectorCascadeRisk by focusing specifically on the squeeze metric.
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 gauging funding-squeeze conditions and offers an interpretive rule ('High score + confirming cascade risk = the unwind has started'), but it does not explicitly state when to prefer this tool over related siblings such as chainvectorCascadeRisk or chainvectorStrategySqueeze.
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 that clusters are 'estimated' and built from OI/leverage distributions, but it does not clarify whether this is a real-time or historical read-only operation, nor any limitations such as data recency or accuracy caveats.
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 no wasted words. The first sentence defines what the tool does, the second explains how to interpret it, and the purpose is 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?
Given the tool's moderate complexity and lack of output schema, the description conveys the core output structure (price bins x long/short USD) and interpretation. It could be more explicit about the exact return format, but the essentials are covered.
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 (symbol and window). The description adds no parameter-specific semantics, which is acceptable but not an 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 tool provides a liquidation heatmap with estimated resting liquidation clusters, specified as price bins by long/short USD, built from OI and leverage distributions. This defines the resource and output scope, though it lacks an explicit verb like 'returns' or 'get'.
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 gives clear usage context: price gravitates toward dense clusters, making them natural targets and danger zones for stop placement. It does not mention alternatives or exclusions, but the intended use is evident.
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 notes that the data is 'currently resting in the book' and that walls persist 'until pulled', which hints at the transient nature of the data. However, it does not explicitly state whether the tool is read-only, does not mention any required permissions, or describe error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence defines the output, the second provides trading context, and there is no wasted verbiage.
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?
With no output schema, the description partly compensates by specifying that results include age and distance from mid, and it explains the conceptual significance of walls. It lacks details on output structure, sorting, or whether bid/ask sides are included, but given the tool's narrow scope it is reasonably 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, so the baseline is 3. The description uses the 'min_usd' parameter ('>= min_usd') but adds no meaning beyond the schema's own description of the threshold and defaults. Other parameters like symbol, window, and exchange are not elaborated in the description.
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 identifies the tool as providing ChainVector resting liquidity walls—unusually large limit orders currently in the book, including age and distance from mid. This sets it apart from sibling tools like chainvectorOrderbookImbalance or BinanceDepth. However, it lacks an explicit action verb like 'get' or 'list', making the purpose slightly indirect.
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 explains that walls serve as magnets/support and are natural take-profit and stop anchor levels, giving a clear use case. It does not explicitly mention when to avoid this tool or name alternative tools for other use cases, so it stops short of full 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, the description carries the burden. It discloses that the tool executes a conversion, indicating a mutating operation, but does not mention irreversibility, invalid quote handling, or other consequences.
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?
One concise, front-loaded sentence with no wasted words. It effectively communicates the core action and prerequisite.
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 execution tool, the description is adequate but minimal. It doesn't explain return values or error conditions, and there is no output schema to fill the gap.
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 both parameters, so the tool adds little beyond noting quoteId's role. The baseline of 3 is appropriate because the description does not provide extra parameter details.
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 uses specific verbs 'confirms and executes' and identifies the resource as a 'token conversion using a previously received quote ID'. This clearly distinguishes it from quote request or order status 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?
It provides a clear prerequisite context ('previously received quote ID'), implying the tool is used after a quote request. However, it does not explicitly name alternatives or exclusions, so it stops short of a full 5.
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 must convey behavioral traits. It does disclose read-only behavior ('retrieves') and pagination support (limit up to 1000). However, it does not mention authentication prerequisites, potential rate limits, or what fields are returned, leaving a moderate transparency 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, well-structured sentence. It front-loads the core purpose and then adds the key pagination detail. There is zero fluff, every word earns its place.
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?
The tool is relatively simple (4 params, no output schema), so the description covers the basics: what it does, time range, and pagination. However, since there is no output schema, it would be more complete to hint at the structure of the returned trade history (e.g., a list of trade objects). The description is adequate but not fully self-sufficient.
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 descriptions cover 100% of parameters, so the baseline is 3. The description adds little beyond the schema: it mentions the limit parameter's max (already in schema) and the time range (already described via startTime/endTime). It does not clarify parameter types, units, or relationships beyond what the schema provides.
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 ('retrieves') and the specific resource ('token conversion trade history'), and it distinguishes this tool from sibling trade history tools like BinanceGetC2CTradeHistory by explicitly naming 'token conversion'. It also specifies the time range scope, 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 gives clear context: it is for retrieving the user's token conversion trade history within a specified time range. It does not explicitly exclude alternatives or mention when not to use it, but the unique resource type makes the intended use clear. However, with many sibling tools, a brief note on when to prefer this over similar trade history tools would have been better, so it misses a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior (staking SOL, receiving BNSOL) and the response content (BNSOL amount and exchange rate). However, it does not mention that the user's SOL balance will be deducted, whether staking is reversible, or any other side effects or prerequisites beyond the amount.
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 two sentences and gets to the point quickly. However, the phrase 'Subscribe SOL Staking API' at the beginning is slightly redundant with the tool name, but it does not detract significantly from clarity.
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 (2 parameters, no output schema), the description covers the essential aspects: what it does, the required parameter, and the response's key fields. It would benefit from clarifying that this is a one-time staking action (not a recurring subscription) and that SOL is deducted from the account, but overall it is reasonably complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 explains both 'amount' and 'recvWindow'. The description only reiterates that the amount is in SOL and required, adding no additional meaning beyond what the schema provides. 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 function: 'stake SOL and receive BNSOL in return' with a specific verb and resource. It distinguishes itself from sibling tools like BinanceSubscribeEthStaking and BinanceRedeemSol by explicitly naming SOL staking and the BNSOL output.
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 implies the tool should be used when a user wants to stake SOL, and it explains the required input (amount of SOL). However, it does not mention alternatives or exclusions (e.g., 'for redeeming BNSOL, use BinanceRedeemSol'), so it lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only says 'Get'. This implies a read-only operation and no side effects, but it does not mention authentication, rate limits, return format, or that the time is likely a millisecond timestamp. It is adequate but minimal for a simple read 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 one short sentence, front-loaded and free of filler. Every word is necessary to convey the tool's purpose.
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?
For a zero-parameter, no-output-schema tool, the description fully conveys what the tool does. The result ('current server time') is self-explanatory, so no additional detail is required.
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, so the input schema contributes nothing. The base score for zero-parameter tools is 4, and the description does not need to explain parameters. It correctly adds no irrelevant parameter details.
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 uses a specific verb 'Get' and a clear resource 'current server time from Binance API'. It directly states the function and distinguishes itself from other Binance tools by its unique focus on server time.
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. For example, BinancePing might serve a similar connectivity-check purpose, but there is no mention of this or any other exclusions or prerequisites.
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 the data source (listed option prices) and the derived output (risk-neutral distribution), but omits behavioral details such as response format, potential errors when no option chain is available, and the effect of the 'target' parameter on the result. This is adequate but not comprehensive.
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: the first sentence defines the tool's purpose, and the second gives actionable usage guidance. Every word earns its place, with no redundancy or filler.
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 lack of an output schema and annotations, the description explains the concept but not the expected response shape, how the optional 'target' affects the output, or failure scenarios. It is sufficient for a well-known financial concept but incomplete for a fully autonomous 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 input schema has 100% coverage with descriptive parameter documentation (e.g., expiry date filter format, optional strike/price). The tool description adds no additional per-parameter meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts a risk-neutral probability distribution from listed option prices, with a specific output concept (P(price above/below strikes at expiry)). It distinguishes itself from the sibling 'chainvectorProbability' by explicitly grounding it in options-market data and positioning it as a cross-check.
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 usage context: 'Cross-check the probability engine against what option traders are paying for' implies comparing with the general probability tool. However, it does not explicitly state when to use this tool instead of alternatives or list exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing behavior. It thoroughly explains the trigger logic (score threshold, breadth, dispersion, order book lean, liquidation cascade) and the return format (triggered true/false plus blockers). It does not mention side effects or permissions, but as a strategy evaluation tool, this level of detail is substantial.
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 concise, with two sentences that front-load the purpose and then list trigger conditions. It is dense but not overly verbose; every clause provides meaningful condition detail 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 has 3 simple parameters, no output schema, and no annotations, the description provides adequate context by summarizing the decision logic and return type. It could be more complete by detailing the structure of 'blockers', but for a strategy template with this parameter complexity, the information is reasonably sufficient.
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 provides 100% coverage with clear descriptions for all three parameters (symbol, min_score, min_breadth), including defaults and ranges. The description adds minimal extra meaning beyond the schema, mostly referencing min_score and breadth conditionally, but no new syntax or format details are introduced.
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 identifies the tool as a 'Momentum-continuation template' with a specific trigger condition list, and explicitly states the return value (triggered true/false plus blockers). This distinguishes it from sibling strategy tools like chainvectorStrategyMeanRevert or chainvectorStrategySqueeze.
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 momentum-continuation setups by describing the conditions that trigger it, but it does not explicitly provide when-to-use versus alternatives, nor does it state exclusions or mention other strategy templates by name. The differentiation is only implicit via the 'momentum' label.
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 transparency burden. It clearly indicates a read operation ('Retrieve') and discloses the output structure (hourly/daily hashrate, timestamps, rejection rates). It does not mention pagination or data range, but for a read-only reporting tool this is adequate.
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, front-loaded with the primary action and resource, followed by concise details about return data. No filler or redundant 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?
With no output schema, the description's explanation of return values is important, and it covers key elements (hourly/daily hashrate, timestamps, rejection rates). It is sufficiently complete for two required parameters and a clear scope, though mentioning time range boundaries or pagination would make it more 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 already provides full descriptions for all three parameters (algo, userName, recvWindow), so the description adds no additional parameter-level meaning. The mention of 'mining account' reinforces userName but does not go beyond the schema.
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 retrieves hashrate statistics for a mining account, with a specific verb ('Retrieve') and resource. It also details the return content (hourly/daily data, timestamps, rejection rates), distinguishing it from sibling mining tools like earnings or resale lists.
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 this tool is for mining account performance monitoring, but it does not explicitly state when to use it over alternatives such as BinanceMiningAccountEarning or BinanceStatisticList. There are no exclusions or alternative tool suggestions, so usage guidance is only implied.
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 burden of behavioral disclosure. It adds value by specifying the return fields (name, ID, sequence, unit), implying a read-only list operation. However, it does not mention authentication requirements, rate limits, or potential errors, leaving gaps in full 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 a single, concise sentence that is front-loaded with the verb and resource. Every word earns its place; no filler or 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 simple tool with no parameters and no output schema, the description adequately explains the purpose and return fields. It might benefit from noting any prerequisites or whether it requires authentication, but given the simplicity, it is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the baseline for no parameters is 4. The description does not need to add parameter details because there are none, and schema coverage is effectively 100%.
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 ('Retrieve') and the resource ('a list of available mining algorithms'), and lists the specific fields included ('name, ID, sequence, and unit'). This distinguishes it from sibling tools like BinanceAcquiringCoinName, which focuses on coin names.
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 one needs mining algorithm information, but it does not explicitly state when to use this over alternatives or provide exclusions. The context among mining-related siblings suggests a niche purpose, yet no direct guidance is given.
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 transparently indicates a read-only operation via 'Retrieves' and lists the output fields, giving a clear sense of what the tool does. It doesn't mention rate limits or pagination, but for a simple read query, the description provides adequate 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, well-structured sentence that immediately states the main purpose and then lists key output details. No fluff or unnecessary 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 that the tool has only one optional parameter, no output schema, and no annotations, the description is reasonably complete. It explains what the tool returns and the scope (open limit orders). It could mention that it requires authentication, but that is implied by the Binance tool family and is not a significant gap.
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% (only recvWindow, with its own description). The tool description does not add any additional meaning about the parameter, so the baseline 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 uses a specific verb ('Retrieves') and clearly identifies the resource ('all your open limit orders for token conversions'). It also lists the returned details (assets, amounts, exchange rate, order status, expiration time), which distinguishes it from other order-related tools in the siblings list.
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 the tool is for viewing open conversion limit orders but doesn't explicitly state when to use it versus alternatives like BinanceConvertOrderStatus or BinanceGetOpenOrders. No exclusions or alternative tools are mentioned, so guidance is implied rather than explicit.
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, the description carries the full transparency burden. It discloses that the operation is a read-only retrieval and lists the types of details returned, but it does not mention pagination behavior, authentication requirements, or potential rate limits, which are relevant for a history endpoint.
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, well-structured sentence that efficiently communicates the tool's purpose and the major fields involved, with no wasted words or unnecessary repetition.
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?
The description adequately covers the scope ('own past C2C trades'), the type of data returned (asset type, direction, fiat, status), and implicitly the historical nature. Given that the schema fully documents all parameters, this is sufficient for a simple read-only tool, though it could mention pagination or time constraints.
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 already provides descriptions for all four parameters, so the description does not add significant new parameter-level semantics. It only gives a general overview of the data returned, 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 tool's function with a specific verb ('retrieve') and resource ('own past C2C trades'), and distinguishes it from sibling tools like BinanceGetPayTradeHistory or BinanceGetFiatPaymentsHistory by specifying C2C trades.
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 that this tool is for retrieving the user's own C2C trade history, which implies when to use it. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It explicitly states this is a GET fetch, implying read-only behavior, and lists the types of records returned. However, it omits other behavioral details like authentication requirements, pagination behavior, or whether both sent and received transactions are included, which would enhance 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 a single, front-loaded sentence that efficiently conveys the tool's purpose and scope. Every phrase adds value, listing concrete transaction types without 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 relatively simple tool with four optional parameters and no output schema, the description provides a solid overview of what is returned (transaction records with examples). It lacks some context like account scope or time-range semantics, but the core behavior is adequately conveyed. Without annotations, a bit more detail could be expected, but the listing of covered transaction types makes it reasonably 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 already provides descriptions for all four parameters with 100% coverage, so the baseline is 3. The description does not add extra meaning about how parameters like startTime/endTime filter results or how limit behaves beyond the schema's own text, so it neither boosts nor detracts.
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 retrieves Binance Pay trade history via GET, and enumerates specific transaction types (C2C transfers, merchant payments, crypto box activity, refunds, payouts, remittance). This verb+resource structure effectively distinguishes it from sibling tools like BinanceGetC2CTradeHistory and BinanceGetFiatPaymentsHistory.
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 implies usage by enumerating covered transaction types, giving context for when to use this tool (e.g., when needing Pay-related history). However, it does not explicitly name alternatives or exclusions, such as when to use BinanceGetC2CTradeHistory instead, so it falls short of the highest bar.
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 burden of indicating behavior. It correctly implies this is a read-only operation via 'retrieves' and scopes to SPOT TWAP orders. However, it does not disclose any limitations, pagination, or authentication requirements, which is a gap for a tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and free of unnecessary detail. It earns its place by specifying the exact scope without padding.
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 simplicity (one optional parameter, no output schema), the description adequately conveys what the tool returns. It does not explain return structure, but for an open-orders retrieval tool, the item type is implied. A mention of which account or symbol scope could improve completeness, but not essential here.
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 covers the only parameter (recvWindow) with a brief description, achieving 100% coverage. The tool description adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'retrieves all open SPOT TWAP orders on Binance,' providing a specific verb, resource, and scope. It distinguishes itself from siblings by specifying SPOT and TWAP, which separates it from futures algo, historical, and cancel 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 use case is clearly implied: use when you need open SPOT TWAP orders. However, it does not explicitly mention when not to use it or name alternatives, such as using BinanceGetOpenOrders for regular open orders or BinanceFutureCurrentAlgoOpenOrders for futures.
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, the description must carry the behavioral disclosure burden. It correctly implies a read-only operation via 'Get' and reveals the 'or all symbols' behavior, but it does not mention output shape, symbol formatting, response size implications, or potential errors. This is minimal but acceptable for a simple read-only 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 a single concise sentence, front-loaded with the verb and object, and contains no filler or redundant information. It effectively communicates the tool's purpose in just nine 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 simple tool with one optional parameter and no output schema, the description provides sufficient context to select and invoke the tool: it states the purpose, scope, and the optional behavior. It does not list every returned statistics field, but that does not hinder initial use given the simplicity.
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 describes the single 'symbol' parameter with an example (BTCUSDT), and schema coverage is 100%. The description adds meaning by explicitly stating that the tool works for 'a symbol or all symbols,' which clarifies the optional parameter and the all-symbols case, adding value beyond the schema.
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 uses a specific verb and resource: 'Get 24-hour price change statistics,' which clearly identifies the tool's function and differentiates it from sibling ticker tools like BinanceTickerPrice or BinanceTickerTradingDay. It also includes the scope 'for a symbol or all symbols,' which is a distinguishing capability.
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 the tool is used when 24-hour price change statistics are needed, which provides basic context. However, it does not explicitly state when to avoid this tool or point to alternatives such as BinanceTickerPrice or BinanceTickerTradingDay, which is notable given the large set of sibling ticker tools.
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, the description carries the full burden. It adds a valuable caveat: 'spread_apr is gross carry before fees/slippage,' which clarifies an important limitation. However, it does not disclose other behavioral aspects such as data freshness, return format, or behavior when no pairs meet the OI threshold, leaving some 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 two sentences, front-loaded with the primary purpose, and immediately clarifies the meaning of 'spread_apr' with a caveat. Every sentence earns its place, with no wasted words or 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 simple scan tool with no output schema, the description covers the essential context: what it scans, what it returns (best pair per asset), and the key metric with its caveat. It could be more explicit about output fields or sorting, but it is adequately complete for a 2-parameter tool with high schema coverage.
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 coverage is 100%, with both 'base' and 'min_oi_usd' having clear descriptions. The tool description adds no parameter-specific meaning beyond what the schema already provides, so it meets the baseline for high schema coverage but does not exceed it.
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 performs a 'funding arbitrage scan' and specifies the output: 'best long/short venue pair per asset by annualized funding spread.' This uses a specific verb (scan) and resource (funding arbitrage), and it distinguishes itself from sibling tools like 'chainvectorFundingCurrent' or 'chainvectorFundingWeighted' by focusing on the arbitrage pair selection.
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 implies when to use this tool (when seeking best long/short venue pairs by funding spread) but does not explicitly name alternatives or provide exclusions. The context is clear enough for an agent to infer appropriate usage, but it lacks explicit comparisons to other ChainVector funding 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, the description carries the burden. It discloses output contents (max pain expiry price, open-interest walls by strike) and an insightful behavior ('Price often pins near max pain into large expiries'). This goes beyond a minimal definition, though it omits details like return format or data refresh policies. The provided behavioral insight is genuinely useful and earns 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 three sentences: a clear definition, a list of outputs, and a practical market insight. It is front-loaded and every sentence contributes value without redundancy. Ideal size 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?
For a relatively simple, read-only analytical tool with two optional parameters and no output schema, the description is complete. It explains what the tool does, what it returns, and a relevant behavioral pattern. It does not mention response structure, but that is acceptable given the absence of an output schema and the tool's straightforward nature. A small gap: no explicit note on supported currencies beyond the schema's examples, but overall it is sufficient.
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% coverage with descriptions for both parameters ('Expiry date filter' and 'Underlying'). The description adds no additional parameter-specific semantics, but since schema fully documents them, a baseline of 3 is appropriate. No extra value is needed.
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 identifies the tool's purpose: computing options max pain for ChainVector, defined as 'the expiry price that minimizes total option-holder payout'. It also indicates it returns open-interest walls by strike, which distinguishes it from other chainvector tools like chainvectorOptionsImpliedProbability. The verb 'max pain' and specific resource make it unambiguous.
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 does not explicitly contrast this tool with alternatives. However, the note 'Price often pins near max pain into large expiries' implies relevance for larger expiries, and the parameter description 'omit for nearest' gives basic usage direction. There is no explicit when-to-use vs alternatives, but the name and context convey a clear use case.
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 burden. It discloses that the tool returns live markets and lists the data fields, and points to downstream tools. However, it does not explicitly state that this is a read-only operation, nor does it mention potential side effects, authentication needs, or rate limits. It is adequate but not rich 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 sentences with no wasted words. It front-loads the core purpose and follows with the key downstream relationship, making it easy to scan and understand.
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 simple tool with two optional parameters and no output schema, the description covers the key return fields (market ids, series, strikes, close times) and explains the tool's place in the workflow. It stops short of explicitly stating the response is a list of markets or specifying any default behavior, but is otherwise 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%: both 'venue' and 'series' have descriptions with examples. The description does not add meaning beyond the schema, only referencing output fields such as strikes and close times. This matches the baseline 3 for full 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 uses a specific verb ('discovery') and resource ('prediction-market'), and clearly lists the output fields (venue market ids, series, strikes, close times). It distinguishes itself from sibling tools by explicitly stating that the market_id values feed the stability/edge/quotes tools, establishing a unique role.
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 implies when to use the tool: to discover live Polymarket/Kalshi markets before using downstream tools. It provides clear context ('market_id values feed the stability/edge/quotes tools') but does not explicitly state when not to use it or name alternative discovery tools. This is clear context without exclusions, fitting a 4.
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 present, so the description carries the transparency burden. It discloses cadence, scope (one market), and the YES top-of-book focus, which is helpful. However, it doesn't explicitly state that it's a read-only operation or describe the response format/limitations, leaving 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?
Two concise sentences, front-loaded with the tool's purpose and key characteristics. Every word adds value; no redundancy or filler.
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 simple query tool with one required parameter, the description is mostly sufficient. It explains what data is returned (recent YES top-of-book samples) but lacks detail on exact output fields. Given no output schema, this is a minor gap, but the core purpose is well covered.
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 coverage is 100% and the descriptions for limit, venue, and market_id are clear. The tool description adds no additional parameter-level detail (e.g., how limit maps to time range), so it stays at 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 explicitly states it provides prediction-market quote history with specific details (recent YES top-of-book samples, ~10s cadence, one market). This clearly distinguishes it from sibling tools like chainvectorPredictionsTrades or chainvectorPredictionsMarkets.
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 phrase 'Reconstructs how the crowd repriced an outcome' provides clear context for when to use this tool—analyzing historical price movement for a single market. It doesn't explicitly cite alternatives or exclusions, but the intended use case is evident.
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, the description must carry the full burden of behavioral disclosure. It describes the data nature (taker tape, YES vs NO lifts) but does not explicitly state that it is a read-only query, the return format, or whether results are ordered/aggregated beyond the 'limit' parameter. This is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core concept ('taker tape') and elaborates with key details (YES vs NO, price, order-flow context). No wasted words; it is easily scannable and appropriately sized.
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 simple read-only data tool with no output schema, the description covers the essential 'what' (taker tape, YES vs NO, price) and the context (order flow). It could mention whether it returns raw trades or aggregated data, or how rows are ordered, but given the low complexity, this is 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?
Schema description coverage is 100%, with all three parameters documented (series, limit, venue). The description adds no extra meaning beyond the schema—'across a series' simply reinforces the series parameter. Baseline 3 applies because the schema already handles parameter semantics.
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 identifies the tool's function: it provides prediction-market taker tape for a series, showing who is lifting YES vs NO at what price. This specific verb+resource framing distinguishes it from sibling tools like quotes (passive) or markets (listings), 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 phrase 'Order-flow context for an outcome' gives clear context for when to use the tool—when analyzing aggressive order flow in prediction markets. However, it does not explicitly name alternatives or state conditions like 'use this instead of quotes for aggressive flow,' so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It implies a read-only historical replay (non-destructive) and mentions the type of data returned (momentum, whale pressure, regime). However, it does not explicitly state safety, permissions, or response format, leaving gaps for the agent to infer.
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, front-loaded with the tool's purpose and supported by use cases. Every sentence earns its place, with no wasted words or 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 no output schema and 5 parameters, the description provides a clear purpose and use cases, making the tool understandable. It lacks a description of the return format (e.g., structure of snapshot/regime samples), but the essential context is covered for a historical data retrieval 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 input schema has 100% parameter descriptions, so baseline is 3. The description adds context about assets and signal types but does not add meaning beyond the schema, such as the meaning of interval buckets or from/to range details, which are already covered in the schema.
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 replays past snapshot and regime samples for specified assets (BTC/ETH/SOL/XRP/DOGE) to observe how momentum, whale pressure, or regime evolved. It distinguishes itself from siblings like chainvectorSignalsSnapshot (current) and chainvectorMomentum (single metric) by focusing on historical replay.
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 use cases: backtesting a strategy template and explaining changes before a move. However, it does not explicitly name alternative tools (e.g., chainvectorSignalsSnapshot for current state) or state when not to use it, so it stops short of full exclusionary 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, the description carries the full burden. It discloses the composite nature and that all data is 'sampled at the same instant,' which is useful. However, it does not mention the return format, whether authentication is required, or error behavior, leaving 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?
Two sentences, information-dense with no redundant wording. It front-loads the tool's purpose and lists the included signals efficiently, earning each sentence's 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 composite snapshot tool with no output schema, the description comprehensively enumerates the signal components and the intended pre-trade use case. It lacks explicit output structure but covers purpose, scope, and timing well, especially given sibling tools exist for individual signals.
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 provides 100% coverage of both parameters, including descriptions for symbol and min_notional. The description's mention of 'whale threshold' mirrors the schema without adding new meaning. Per calibration, baseline 3 applies 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 defines this as a one-call bot decision snapshot for a base asset, listing concrete components (momentum scorecard, order-book imbalance, whale pressure, liquidation cascade risk, OI-weighted funding, squeeze gauge). Its 'snapshot' framing and aggregation of multiple signals distinguishes it from single-signal siblings like chainvectorMomentum and chainvectorSignalsHistory.
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 the intended use case: reading the whole signal stack 'before a trade' in the 'cheapest way,' which implies it is best used when wanting a consolidated overview rather than individual metrics. It does not name alternative tools or exclusions, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It accurately states this is a read operation that 'retrieves a list', but adds no context about authentication, pagination, or response structure. It is not misleading but remains minimal.
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, well-structured sentence with no redundancy. It efficiently communicates the tool's purpose and scope without unnecessary words.
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 low complexity (one optional parameter, no output schema), the description is complete enough for an agent to understand what the tool does and what it returns. It clearly states the scope (futures, USDⓈ-M) and the resource type (current algo open orders), making it sufficient for correct 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?
The input schema has 100% coverage for the single parameter (recvWindow) with an inline description. The tool description does not add any additional meaning or syntax details beyond what the schema already provides, so it provides no 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 uses a specific verb ('retrieves') and identifies the resource as 'currently active algorithmic orders for USDⓈ-M Contracts in Binance Futures'. This clearly distinguishes it from siblings like BinanceSpotCurrentAlgoOpenOrders (spot) and BinanceFutureHistoricalAlgoOrder (historical).
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 specifying the market (USDⓈ-M futures), which implies when to use this tool versus spot or historical alternatives. However, it does not explicitly name alternatives or state exclusions, so it stops short of full 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, the description carries the full behavioral burden. It discloses the core rules of the strategy—buying flushed long side or selling flushed short side, waiting for burst < rate, and avoiding accelerating cascades. However, it does not indicate whether the tool is a pure signal generator or has side effects, nor describe its output format.
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, front-loaded with the key concept, no fluff. The jargon is dense but purposeful.
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?
The description explains the strategy logic but omits any indication of the return value or output structure, which is significant since there is no output schema. It does mention heatmap clusters as a target, but not how the tool is invoked or consumed.
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 coverage is 100% with clear descriptions for both parameters. The description adds no additional parameter semantics, but the baseline is appropriate given the 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 identifies the tool's purpose: fading an exhausting liquidation cascade. It uses a specific verb ('fade') and names the resource ('liquidation cascade'), and the distinction from sibling momentum/revert/squeeze strategies is evident.
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 gives explicit usage conditions: only fade an exhausting cascade when forced closing cools off (burst < rate), and never when the cascade is still accelerating. It does not name alternative tools but the conditions clearly differentiate when this strategy is appropriate.
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 transparency burden. It discloses a key behavioral constraint (7-day default, 30-day maximum range) that is not fully evident from the schema alone. However, it does not explicitly state read-only side effects, pagination behavior, or what the response contains, so it falls short of fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the primary purpose and key constraints. Every word adds value, with no redundancy or filler.
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 simplicity of the tool (4 optional parameters, no output schema, no annotations), the description covers the core essentials: what it retrieves and the time constraints. It omits specifics about response structure and pagination, but these are partially inferable from the schema and the nature of history tools, making the description reasonably complete.
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 already covers all parameters with descriptions, giving a baseline of 3. The description adds meaning beyond the schema by explaining the default behavior of time parameters (past 7 days) and the maximum allowed range (30 days), which clarifies how startTime/endTime should be used.
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 uses a specific verb 'Retrieve' and clearly identifies the resource as 'history of spot rebate records' with examples of content (commission rebates and referral kickbacks). This distinguishes it from the many other Binance tools in the sibling list, such as wallet asset records or mining payment 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 the tool: for spot rebate history, with a default of the past 7 days or a custom range within 30 days. While it doesn't explicitly name alternatives, the unique domain (spot rebates) makes the use case clear, and the time-range constraint guides callers on parameter usage.
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 discloses key behavioral aspects: normalization to a common scale, inclusion of countdown, and interpretation of extreme funding as a squeeze signal. This goes beyond the name and adds meaningful context, though it does not address return format or potential caveats.
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 concise sentences deliver the core functionality and a practical interpretation. No wasted words; information is front-loaded 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?
For a simple one-parameter data query with no output schema, the description covers the data scope, normalization, countdown, and meaning of extreme funding. It lacks explicit return-format details but is otherwise adequate.
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 coverage is 100%: the only parameter 'symbol' is fully described with a case-insensitive substring filter example. The tool description adds no additional detail about the parameter, so it relies on the schema's already-sufficient 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 tool's function: providing current funding rates across every tracked perp venue, normalized to a common scale with countdown. This is specific and distinguishes it from siblings like chainvectorFundingWeighted and chainvectorFundingArbitrage.
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 gives clear context for when to use the tool—when you need current funding rates across venues with a common scale and countdown. However, it does not explicitly mention alternatives or exclusions, such as 'for weighted funding use chainvectorFundingWeighted.'
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 transparency burden. It explains the weighting behavior (open interest weighting, large venues dominate, outliers don't distort), which is meaningful behavioral context. It does not mention return format, units, or update frequency, but the 'one number' phrase conveys the output shape.
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, tightly worded sentence that front-loads the tool's identity and explanation. Every phrase earns its place, with no redundancy or filler.
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 simple one-parameter schema and no output schema, the description is mostly complete: it explains the metric's purpose, weighting logic, and output as a single number. It could add details like data source, freshness, or units, but the core decision-making context is present.
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 fully documents the optional 'base' parameter with a clear example and instruction to omit for all assets. The description adds the 'per asset' context but does not explain parameter syntax beyond the schema, so baseline coverage is sufficient.
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 identifies the tool as a composite funding metric per asset, with specific verb 'summarizes' and resource 'OI-weighted funding composite'. It distinguishes itself from sibling funding tools like chainvectorFundingCurrent by emphasizing open-interest weighting and market-wide aggregation.
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: when a single, venue-weighted funding number is needed, with large venues dominating and small outliers not distorting the value. However, it does not explicitly name alternatives or state when not to use it, though the weighting rationale implies differentiation from simpler funding 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, the description carries full burden. It discloses deterministic results ('Same numbers every agent run'), server-side computation, and the tick-derived bar source. It lacks details on return structure or limits, but these are partially covered by the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the core purpose and include a key benefit (deterministic, server-side). No wasted words; every clause 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?
The description covers what indicators, intervals, and computation model are used, which is sufficient for a read-only analytics tool. It doesn't describe return shape, but the schema's parameter descriptions and the tool's simple nature make this adequate.
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 documents all 5 parameters. The description adds value by mapping the indicator list to the 'indicators' parameter and reiterating the interval range, but provides no additional semantics beyond the schema.
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 computes technical indicators (RSI, EMA/MA ladder, MACD, ATR, Bollinger bands) on server-side tick-derived bars with interval support. This specific verb+resource combination distinguishes it from sibling analytics 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?
It provides clear context: this is the server-side, deterministic indicator source, contrasting with local candle math. While it doesn't explicitly name alternative tools, the 'no local candle math' phrase implies when to prefer it over manual computation or raw kline 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, the description carries the full burden. It discloses the score's interpretation (positive = rising), the range (-100..+100), and the provided metrics. It does not discuss permissions or side effects, but this is a read-only analysis tool, so those are less critical. The semantic guidance adds solid 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 compact and information-dense. It front-loads the key output fields and follows with a clear usage rule. Every sentence adds value, and there is no redundant or vague wording.
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 there is no output schema, the description sufficiently explains the return metrics and how to apply them. It covers the key interpretive details (score range, direction, veto threshold). Minor omissions like the exact structure of the per-venue breakdown are acceptable given the tool's analytical 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 input schema already provides complete descriptions for both parameters (type and symbol). The tool description does not add any parameter-specific details beyond the schema, so the baseline 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 identifies this as a cross-venue futures momentum scorecard and specifies the exact output fields (aggregate score, per-venue breakdown, breadth_up, score_dispersion). The scope and nature are unambiguous, distinguishing it from general market data 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?
Explicit usage guidance is provided: use as an EV weight when agreeing with a trade idea and as a veto when |score| >= 60 opposing. This is actionable, though it does not mention alternative tools or explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It specifies the output scale, sign convention, units (bps for microprice tilt), and adds an interpretive rule. It does not cover response structure or update cadence, but the core semantics are well explained.
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 effectively front-load the definition and provide interpretation without redundancy. No filler words, and the structure is easy to scan.
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?
The description covers the metric's meaning, range, and decision relevance, and the schema documents all parameters. Missing an explicit statement of return type, but given the simple metric and no output schema, the information is mostly sufficient.
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?
All three parameters have schema descriptions (100% coverage), so the baseline is 3. The description's mention of '5/10/20 levels' aligns with the depths parameter default but does not add semantic detail beyond what the schema already provides.
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 identifies the specific metric (order-book depth imbalance) and adds distinguishing details: level counts (5/10/20), value range [-1, +1], polarity (+ = bid-heavy), and a microprice tilt in bps. This clearly differentiates it from sibling chainvectorOrderbookWalls and chainvectorOrderflowCvd.
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 second sentence explicitly frames the tool's relevance to trading decisions: a book leaning against a candidate trade is a warning, leaning with it is confirmation. This gives clear context for when to apply the metric, though no explicit alternatives or exclusions are mentioned.
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 the full burden. It adds behavioral context beyond the schema by explaining that CVD is cross-exchange aggregated and that rising CVD indicates net aggressive buying, plus a warning about fade signals. It does not disclose all caveats (e.g., return format, latency), but it is informative.
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 three sentences, front-loaded with the core definition, followed by interpretation and usage guidance. Every sentence earns its place with no redundancy or fluff.
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?
The description explains the tool's purpose and interpretation, which is sufficient for a data metric tool with well-described parameters. It lacks a detailed return format specification, but the absence of an output schema means the description covers the most critical context. Overall, it is complete enough for the agent to select and use the tool correctly.
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?
All parameters are fully described in the schema (100% coverage), so the baseline is 3. The description does not add any additional parameter-specific meaning beyond the schema, which already explains symbol substring matching, exchange aggregation, and interval enums.
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 what the tool does: 'buy vs sell taker volume per bucket, cross-exchange aggregated.' It specifies the resource (CVD) and the metric (taker order-flow), making it distinct from sibling tools like orderbook imbalance or funding.
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?
Provides clear usage context: 'Confirm a direction before entering: flow against the trade is the classic fade signal.' This tells the agent when to use the tool (before entering trades) and how to interpret the data, though it does not explicitly name alternative tools 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 discloses the output fields and explains the interpretation of a positive buy_edge ('the market underprices the outcome per the model'). It also notes that edges are 'net of the spread.' However, it doesn't explicitly state that this is a read-only query or mention any rate limits or connection behaviors, which prevents a perfect score.
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. The first sentence defines the tool and lists its outputs; the second clarifies the meaning of a positive buy_edge. Every phrase earns its place, with no redundancy or filler.
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 only two parameters (one required) and a query-like purpose, the description is largely complete. It names the four output fields, which mitigates the lack of an output schema. The only minor gaps are the absence of an explicit read-only statement and the lack of any mention of potential errors or rate constraints, but these are not critical for such a simple 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%: both 'venue' and 'market_id' include descriptions in the schema. The tool description does not add additional parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate. It does indirectly imply that market_id refers to the market being analyzed, but that is already captured in the schema.
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: computing the 'model-vs-market edge' by repricing the ChainVector probability-engine ensemble against a prediction market's live quote. It names the specific output fields (model_prob, market_prob, buy_edge, sell_edge) and distinguishes itself from sibling tools like chainvectorPredictionsQuotes and chainvectorProbability by combining both into an edge metric.
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 clearly implies when to use this tool: when you need to compare ChainVector model probabilities against a market's live quote to assess edge. It doesn't explicitly name alternatives or exclusions, but the phrase 'model-vs-market edge' sets it apart from related tools that provide only quotes or probabilities.
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, the description carries full behavioral burden. It discloses internal methodology (six-estimator convex ensemble, tick-derived 1m bars) and the semantics of kind and horizon. However, it doesn't describe the return value format or potential failure modes, which would be valuable for a probability engine.
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 dense and front-loaded with the core purpose. Each sentence adds distinct value (methodology, kind variants, horizon flexibility, use cases). Slightly long, but no redundancy; structure is logical.
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 (9 params, three kinds, no output schema), the description covers purpose, parameter interplay, and use cases thoroughly. It doesn't explicitly state the return format, but the probability semantics are well explained. Considerable effort to make the tool self-documenting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds significant contextual meaning: explains kind=touch and kind=range semantics, target ladder syntax via 'targets', and how close_ts overrides horizon. This goes well beyond 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 tool's function: computing probability of price hitting a target using a six-estimator ensemble. It distinguishes itself from sibling tools by specifying the probability engine nature and the different kinds (terminal, touch, range).
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?
Provides explicit use cases ('take-profit/stop placement', 'pricing any binary outcome') and explains when to use each kind and how close_ts overrides horizon. Lacks explicit exclusions or alternatives, but context is strong enough for an agent to select it appropriately.
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 the full burden of behavioral disclosure. It discloses the output fields (regime, direction, 0-1 confidence, rationale) and the decision mapping to strategy templates. While it does not mention side effects or auth requirements, as a classifier these are not expected, making the behavior sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, both dense with information: the first defines the output taxonomy and fields, and the second explains the strategy mapping. There is no filler or redundancy, making it concise 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?
For a single-parameter classifier with no output schema, the description provides a complete picture: it states the output structure and how to interpret the result for strategy selection. Some details like the meaning of direction values are lacking, but overall it is sufficient for an agent to understand the tool's role and 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?
The schema covers 100% of the parameter with a clear description ('Base asset, e.g. BTC'), so the baseline is 3. The tool description adds no additional parameter semantics beyond what the schema already provides, so a 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 identifies it as a market regime classifier with a specific list of regimes (trending, choppy, quiet, squeeze_setup, cascading) and output fields (direction, confidence, rationale). It distinguishes from sibling tools like chainvectorMomentum by explaining that the regime governs which strategy template applies, making its role unique.
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 how the output maps to strategy selection (trending -> momentum, choppy/quiet -> meanrev, etc.), which implies when to use the tool (to decide which strategy template to apply). However, it does not explicitly contrast with alternative tools or state when not to use it, leaving some room for 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?
No annotations are provided, so the description carries the full burden. It explains the index composition (cascade 25%, squeeze 20%, etc.), the meaning of label ranges, and how to act on the value (circuit breaker). This goes beyond the schema and provides practical behavioral context, though it does not describe the exact response structure or mention side effects (irrelevant for a read-only metric).
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 compact and front-loaded with the core definition, followed by the component breakdown, labels, and a practical usage note. Every sentence adds value with no redundancy or filler.
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 simplicity and rich schema, the description is nearly complete: it explains what the index means, how it's computed, how to interpret values, and when to use it. It lacks an explicit return-format description (e.g., JSON keys besides the single number), but for a straightforward index metric the provided information suffices.
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 coverage is 100% and both parameters are well-described in the schema (symbol filter, history boolean). The description adds minimal parameter-specific meaning—only implicitly referencing per-asset vs. composite via 'per asset' and 'market composite'—so it stays at 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 it provides a single 0-100 market-stress number per asset, with explicit component weights and label thresholds. This distinguishes it from sibling chainvector tools (like cascade or funding-only metrics) and states the exact scope ('per asset').
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 an explicit use case: 'Use as a circuit breaker: no new entries while the index is high/extreme.' This gives clear when-to-use guidance. It does not list alternatives or exclusion cases, but for a composite risk index the circuit-breaker framing is strong.
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 transparency burden. It discloses the critical behavior 'Treat action='flat' or any veto as a hard no-trade' and details the decision structure fields. It does not cover error handling or data source specifics, but the core advisory behavior is well communicated.
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: the first packs essential functionality and output fields, the second provides a critical usage rule. No redundancy or filler; every phrase 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?
Given the tool's complexity and lack of an output schema, the description adequately lists the decision output components and the veto rule. It does not explain interpretation or ranges of scores, but it offers enough for an agent to understand what the tool returns and how to act on it.
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 coverage is 100%, so the baseline is 3. The description reinforces parameter roles (horizon for stop/target sizing, risk index for veto) but does not add substantive new meaning beyond the schema descriptions. It references 'requested horizon' and 'risk index' without further elaboration.
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 'Full ChainVector ensemble advisor for a Binance symbol', clearly stating the tool's purpose as a comprehensive decision-maker. It enumerates precise outputs (action, EV score, confidence, veto list, size multiplier, stops/targets) and distinguishes itself from sibling strategy tools by being the 'full ensemble' version.
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 implies this is the go-to tool for a fused, holistic trade decision, contrasting with the more specialized sibling tools like chainvectorStrategyMomentum or chainvectorSignalsSnapshot. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for tool selection.
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 the full burden. It clearly discloses the tool's behavior: it computes and returns probabilistic metrics (P(TP), P(stop), terminal probability, expected move). It also explains the decision criterion (positive expectancy). While it does not explicitly state 'no side effects' or detail underlying model assumptions, the nature of a probability calculation is inherently non-destructive, and the description is transparent about outputs.
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, front-loaded with the core purpose, and each clause adds value. The expectancy formula is a compact but powerful addition. No filler or 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?
The description provides a complete picture of what the tool outputs and when to use it. Given there is no output schema, it lists the four return components and the go/no-go logic. It could mention more about data dependencies or model assumptions, but for invocation selection it is sufficiently complete. It also implicitly differentiates from sibling chainvectorProbability tools by focusing on TP/SL placement.
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 baseline is 3. The description adds some context by linking 'take-profit and stop price' to the relevant parameters and 'horizon end' to the horizon parameter, but it does not go beyond what the schema already describes. It reinforces the meaning without adding new semantic detail.
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 uses a specific verb ('returns') and clearly identifies the resource ('Probability-engine trade plan for an already-chosen direction'). It lists exact outputs (P(TP), P(stop), terminal probability, expected move) and distinguishes from siblings by emphasizing 'already-chosen direction' and 'go/no-go' for TP/SL placement.
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 states when to use it: 'for an already-chosen direction' and 'a quantified go/no-go for exact TP/SL placement.' It implies the tool is for planning entries/exits after direction is set, which is clear contextual guidance. However, it does not explicitly name alternative tools or provide exclusion criteria, so not a 5.
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, the description carries the full burden. It discloses that the tool computes multiple volatility metrics and optional percentile ranking, implying a read-only analytical operation. However, it does not describe output structure, data source specifics beyond the 'exchange' parameter, or potential side effects (e.g., rate limits), leaving some behavioral ambiguity.
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, front-loaded with the core function and immediately followed by concrete use cases. No wasted words or repetition of schema definitions. Every phrase contributes to understanding or usage.
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 absence of an output schema and annotations, the description reasonably covers input semantics (via schema) and intended use. It lists the metrics computed, which gives a reasonable preview of outputs, but does not specify return format, units, or edge cases. Slightly more detail on output shape would make it more complete.
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 coverage is 100%, so the baseline is 3. The description adds meaning by explaining 'expected move over a precise horizon' with an example ('37m') and 'percentile rank vs the trailing 7 days', which clarifies the intent of the `horizon` and `percentile` parameters beyond their schema descriptions. The other parameters are adequately described in the schema.
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 computes a 'realized-volatility battery' with specific estimators (close-to-close, Parkinson, Garman-Klass, EWMA), plus optional expected move and percentile rank. This specific verb+resource structure distinguishes it from sibling chainvector tools focused on momentum, regime, or signals.
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?
Explicitly states when to use it: 'to size stops/targets and to detect vol-compression setups'. This provides clear context, though it does not name alternative tools or exclusion criteria. The use cases are actionable and align with the tool's analytical purpose.
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 the full burden. It transparently explains what the scores mean (0-100 for stability, -100..+100 for momentum, 30s/1m/5m windows) and the behavioral interpretation. It does not cover edge cases like missing data or error conditions, but for a read-only analytical tool, the provided context is strong.
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 no wasted words. The first sentence packs the metric definitions and window options; the second provides actionable guidance. It is front-loaded and efficient.
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?
There is no output schema, so the description must explain return values. It fully covers the score names, ranges, semantics, and time windows. Given only two straightforward parameters, the description is complete for selecting and invoking the 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%: venue and market_id are already self-explanatory. The description adds no further parameter-specific meaning beyond the schema, so 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 specifies the tool's focus: 'ChainVector prediction bid-price stability for one market'. It defines the core outputs (stability_score and momentum_score) with ranges and meanings, which distinguishes it from sibling tools like chainvectorPredictionsQuotes or chainvectorMomentum by targeting bid-price stability specifically.
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 a clear decision rule: 'A churning or adversely-repricing quote is an entry veto.' This implies using the tool as a pre-entry stability check and indicates when to avoid entering. However, it does not explicitly discuss alternatives or when-not-to-use scenarios relative to 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, the description explains the tool's core behavior: it outputs a risk score and indicates which side would be force-closed. It also explains the score's composition. However, it doesn't mention update frequency, latency, or whether the score is historical or real-time, which would be useful but not critical.
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, front-loaded with the tool's purpose, then wraps up with actionable trading guidance. Every word earns its place — no filler or 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 no annotations or output schema, the description adequately conveys what the tool returns (risk score and side) and why it matters. It could be more precise about interpreting the 0-100 scale or defining 'exhausting cascade,' but it is fundamentally complete for an AI agent to decide when to use it.
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 only parameter 'symbol' is fully described in the schema (default BTC, base asset). The description adds no additional meaning about the parameter, but the schema already provides 100% coverage, so the baseline 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 tool computes a 0-100 composite liquidation cascade risk score, specifying the components (recent liq burst/rate, OI change, leverage proxy) and the cascade_side output. This distinguishes it from sibling tools like chainvectorLiquidations or chainvectorRiskIndex.
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 gives explicit when-not-to-use guidance ('Never enter WITH a likely cascade against you') and when-to-use as a signal ('an exhausting cascade is the cascade-fade setup'). This tells an agent exactly when to consult this tool before trading.
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 bears the full burden of behavioral disclosure. It clearly conveys a read-only listing operation via the verb 'List', and it outlines the content of the response (setup, regime, signals). While it doesn't explicitly state that it makes no modifications, the listing nature is self-evident. It also adds useful context by indicating this should be the first call for strategy inquiries.
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 exceptionally concise, consisting of two sentences that each serve a distinct purpose. The first sentence front-loads the action and the exact output, while the second provides direct usage instructions. Every word earns its place, with no redundancy or filler.
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 no-parameter, no-output-schema listing tool, the description covers all essential aspects: what the tool does, what it returns, and when to use it. It explicitly names the strategies and the fields returned, giving the agent a clear expectation. It could optionally mention the return format or any potential empty states, but that is not critical for such a simple read-only operation.
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?
This tool has zero parameters, so the baseline score is 4. The empty input schema needs no further explanation, and the description correctly omits any parameter details since there are none. The description adds no parameter semantics because none are required to invoke the tool.
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 uses the verb 'List' and unambiguously identifies the resource as 'ChainVector strategy templates', enumerating them by name. It also specifies the returned information (setup, regime, signals), making the purpose crystal clear and differentiating it from the individual strategy sibling tools like chainvectorStrategyAdvise, which focus on a single strategy.
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 usage guidance: 'Call this first when the user asks what strategies can I run?'. This tells the agent exactly when to invoke this tool. However, it does not explicitly mention alternatives or scenarios where this tool should not be used, such as when the user asks for a specific strategy's details, which are likely covered by sibling tools.
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 burden of behavioral disclosure. It explains the strategy logic and the long/short direction, but does not disclose potential risks, whether positions are actually opened, or any other side effects. For a strategy template tool, the core behavior (generating signals based on conditions) is implied but not explicitly stated.
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 long and packed with information: the regime requirement, the extreme condition, the trade direction, and the mean-reversion target. Every sentence earns its place; no filler or 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?
The description covers the strategy logic and the key conditions, and the schema provides 100% parameter coverage. No output schema exists, so the description doesn't need to explain return values. It could benefit from stating what the tool returns (e.g., signals), but for a 'template' tool, the description is sufficiently complete given the schema.
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 all four parameters. The description adds meaning by explaining how the RSI thresholds relate to the strategy (RSI oversold/overbought and long/short sides), and the context of 'interval' as 'indicator bar interval' is reinforced. The description does not fully elaborate on how the parameters interact, but given full schema coverage, this is adequate.
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 this is a mean-reversion template with specific conditions (choppy/quiet regime, RSI or Bollinger extreme) and the action (long oversold, short overbought, back to mean). It distinguishes from siblings like chainvectorStrategyMomentum and chainvectorStrategySqueeze by naming the template type and the conditions.
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 says when to use it: 'requires a choppy or quiet regime' and warns 'never fade a trend'. It also specifies the indicator extremes (RSI oversold/overbought or close outside Bollinger bands) as triggers, giving clear context for when this strategy is appropriate versus alternatives.
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-mcp-chainvector MCP server](https://glama.ai/mcp/servers/C0inFlips/binance-mcp-chainvector/badges/card.svg)](https://glama.ai/mcp/servers/C0inFlips/binance-mcp-chainvector)

Score Badge

Copy to your README.md:

[![binance-mcp-chainvector MCP server](https://glama.ai/mcp/servers/C0inFlips/binance-mcp-chainvector/badges/score.svg)](https://glama.ai/mcp/servers/C0inFlips/binance-mcp-chainvector)

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/C0inFlips/binance-mcp-chainvector'

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