Aster Finance MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but some overlap exists. For example, 'getAllOpenOrders' and 'queryOpenOrder' could be confused, and 'ticker_24hr', 'ticker_bookTicker', and 'ticker_price' are all price-related but serve different functions. Descriptions help clarify, but the sheer number of tools increases the risk of misselection.
Naming Consistency3/5
Naming conventions are mixed, with some tools using camelCase (e.g., 'getAccountInfo') and others using snake_case (e.g., 'ticker_24hr'). Verb styles vary, such as 'get', 'set', 'place', and 'modify', but they are generally readable. The inconsistency is noticeable but not chaotic.
Tool Count2/5
With 44 tools, the count is too high for typical MCP server purposes, making it heavy and potentially overwhelming for agents. While the domain (finance/trading) is complex, the tool surface could benefit from consolidation or better scoping to reduce cognitive load.
Completeness5/5
The tool set provides comprehensive coverage for a trading platform, including order management, account info, market data, and configuration. It supports full CRUD/lifecycle operations (e.g., place, query, cancel orders) and covers various aspects like funding, leverage, and transfers, leaving no obvious gaps.
Average 2.7/5 across 44 of 44 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits 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?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers no information on traits like read-only status, side effects, authentication needs, rate limits, or error handling. It merely states the action without any operational context, failing to compensate for the lack of structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence, which is appropriately sized for its minimal content. However, it is under-specified rather than efficiently informative, as it lacks necessary details, making it front-loaded but insufficient rather than wastefully verbose.
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 (inferred from financial context), lack of annotations, 0% schema coverage, and no output schema, the description is severely incomplete. It fails to provide essential details on purpose, usage, parameters, or behavior, making it inadequate for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, with one parameter 'symbol' undocumented in both schema and description. The description adds no meaning beyond the schema, such as explaining what 'symbol' represents (e.g., a trading pair) or its format, leaving the parameter semantics entirely unclear.
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 Position ADL Quantile Estimation' restates the tool name with minimal elaboration, making it a tautology. It specifies a verb ('Get') and resource ('Position ADL Quantile Estimation'), but lacks clarity on what ADL stands for or what the estimation entails, failing to distinguish it meaningfully from siblings like getPositionInfo or getForceOrders.
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 on when to use this tool versus alternatives. The description does not mention context, prerequisites, or exclusions, leaving the agent with no indication of its appropriate application relative to sibling tools such as getPositionInfo or getForceOrders.
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 of behavioral disclosure. 'Get income history' only indicates a read operation but provides no information about authentication requirements, rate limits, pagination behavior, error conditions, data freshness, or what constitutes 'income' in this context. For a tool with 5 parameters and no output schema, this leaves critical behavioral aspects completely undocumented.
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 concise at just three words, which could be appropriate if it were more informative. However, this brevity comes at the cost of under-specification rather than efficient communication. While it's front-loaded (the entire description is the purpose statement), it lacks the additional context needed for a tool with multiple parameters and no annotations.
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 complexity (5 parameters, no annotations, no output schema, and many sibling financial tools), the description is completely inadequate. It doesn't explain what 'income' means in this context, how parameters filter results, what the return format looks like, or how this tool differs from other financial data tools. The agent would struggle to use this tool correctly without significant trial and error or external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 5 parameters (endTime, incomeType, limit, startTime, symbol), the description provides absolutely no information about what these parameters mean, their expected formats, or how they affect the query. The description doesn't mention any parameters at all, failing completely to compensate for the schema's lack of documentation. This leaves the agent guessing about how to construct valid requests.
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 income history' is a tautology that essentially restates the tool name 'getIncomeHistory' without adding meaningful specificity. It doesn't clarify what type of income (trading fees, interest, etc.), whose income (account-level, position-level), or what format the history takes. While it includes a verb ('Get') and resource ('income history'), it lacks the specificity needed to distinguish it from potential sibling tools or understand its exact scope.
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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like getAccountInfo, getBalance, getTradeList, and getPositionMarginHistory that might overlap with financial data, there's no indication of whether this tool is for comprehensive income reporting, specific income types, or particular contexts. The agent receives no help in selecting this tool appropriately among the many financial data tools available.
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 carries full burden but offers zero behavioral information. It doesn't disclose that this is a destructive/mutative operation (placing an order), doesn't mention authentication requirements, rate limits, or what happens on execution. The description is completely inadequate for a financial trading 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 extremely concise at just 4 words. While this brevity reflects severe under-specification, the text itself is not verbose or poorly structured - it's just incomplete.
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?
For a complex financial trading tool with 8 parameters, no annotations, 0% schema coverage, and no output schema, the description is completely inadequate. It provides no meaningful context about what the tool does, how to use it, what parameters mean, or what behavior to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning all 8 parameters are undocumented in the schema. The description provides no information about any parameters - not even mentioning the 3 required ones (symbol, side, type). It fails to compensate for the complete lack of schema documentation.
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 'Send in a new order' restates the tool name 'placeOrder' without adding specificity. It uses a vague verb 'send in' rather than clearly stating it creates/submits an order, and doesn't distinguish this from sibling tools like 'placeBatchOrders' or 'cancelOrder'.
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's no mention of prerequisites, when to choose this over 'placeBatchOrders', or what context requires this single-order submission 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?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose if this is read-only, requires authentication, has rate limits, or what the output entails, which is inadequate for a tool with parameters.
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 with one short sentence, which is front-loaded and wastes no words. However, it's overly terse to the point of under-specification.
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 5 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It fails to explain the tool's purpose in context, parameter usage, or expected behavior, making it insufficient for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'force orders' are, how parameters like 'autoCloseType' or time ranges apply, leaving semantics unclear.
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 user's force orders' restates the tool name with minimal elaboration, making it tautological. It specifies the resource ('force orders') but lacks a clear verb beyond 'get' and doesn't differentiate from sibling tools like 'getAllOrders' or 'queryOrder'.
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 on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, leaving the agent 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.
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 'query', implying a read operation, but doesn't specify if it requires authentication, has rate limits, returns real-time data, or handles errors. The description is too vague to inform the agent about key behavioral traits 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words, making it easy to parse. However, it's overly brief to the point of under-specification, which slightly reduces its effectiveness, but it remains well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, 0% schema coverage, no output schema, and no annotations), the description is incomplete. It doesn't explain parameter usage, return values, or behavioral aspects, leaving significant gaps for the agent to operate correctly in a context with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions no parameters, failing to explain the meaning of 'orderId', 'origClientOrderId', or 'symbol' (which is required). This leaves the agent guessing about how to use these inputs effectively, with no added value 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 'Query current open order' restates the tool name 'queryOpenOrder' with minimal elaboration, making it tautological. It specifies the action ('query') and resource ('open order') but lacks specificity about what 'query' entails (e.g., retrieve details, check status) and doesn't distinguish it from sibling tools like 'getAllOpenOrders' or 'queryOrder', 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?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't clarify if this is for a single order versus multiple orders (compared to 'getAllOpenOrders'), or how it differs from 'queryOrder' (which might handle closed orders). The description offers no context on prerequisites, exclusions, or typical use cases.
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 carries full burden for behavioral disclosure. 'Transfer between futures and spot' implies a mutation operation but reveals nothing about permissions required, rate limits, transaction finality, error conditions, or what happens to the transferred assets. For a financial transfer tool with 4 required parameters, this represents a critical lack of behavioral 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 extremely concise at just 4 words, which is appropriate for a simple concept. However, this conciseness comes at the cost of completeness. The single sentence is front-loaded with the core action but lacks necessary elaboration for a financial transfer operation.
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?
For a financial transfer tool with 4 required parameters, no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It provides no information about what the tool returns, error conditions, side effects, or the semantics of the transfer operation. The agent would struggle to use this tool correctly without significant external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'futures and spot' which relates to the kindType enum, but provides no explanation of what 'FUTURE_SPOT' versus 'SPOT_FUTURE' means, no context for the amount parameter, no explanation of what asset strings represent, or what clientTranId is used for. The description adds minimal value beyond what the bare schema provides.
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 'Transfer between futures and spot' states the action (transfer) and resources (futures, spot), but is vague about scope and lacks specificity. It doesn't distinguish this tool from potential sibling tools like modifyPositionMargin or setMarginType that might also involve asset movements. The purpose is understandable but insufficiently detailed for precise tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, constraints, or typical use cases. Given the sibling tools include various order and position management functions, the agent receives no help in distinguishing this transfer operation from other asset movement operations.
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 of behavioral disclosure. It only states the action ('Place multiple orders') without any details on permissions, rate limits, side effects (e.g., financial transactions), error handling, or response format. This is inadequate for a tool that likely involves significant mutations and risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence 'Place multiple orders.', which is front-loaded and wastes no words. However, this conciseness comes at the cost of completeness, as it lacks necessary details for effective tool use.
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 complexity of placing multiple orders (likely involving financial transactions), no annotations, 0% schema description coverage, and no output schema, the description is severely incomplete. It does not address behavioral aspects, parameter meanings, usage context, or expected outcomes, making it inadequate for safe and effective agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not add any parameter semantics beyond the name 'batchOrders'. It fails to explain what 'batchOrders' contains (e.g., array of order objects with price, quantity, side, symbol, type) or provide context on required fields, enums, or constraints, leaving parameters largely undocumented.
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 'Place multiple orders' clearly states the verb ('Place') and resource ('orders'), but it is vague about scope and lacks differentiation from sibling tools like 'placeOrder' (which likely handles single orders). It does not specify the context (e.g., trading platform or order types), making it minimally adequate but with gaps in 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?
No guidance is provided on when to use this tool versus alternatives such as 'placeOrder' for single orders or other order-related tools like 'cancelBatchOrders'. The description implies usage for batch operations but does not clarify prerequisites, constraints, or typical scenarios, leaving the agent to infer context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states a read operation ('Get'), implying it's likely safe and non-destructive, but doesn't cover aspects like authentication needs, rate limits, error conditions, or what the return format might be. The description is minimal and lacks 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse. However, it's front-loaded but under-specified, as it could benefit from more detail without sacrificing brevity. Every word earns its place, but the overall content is sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a read operation with 1 parameter), no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't provide enough context for an agent to reliably invoke the tool, such as parameter semantics, return values, or behavioral traits. More detail is needed for adequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the description doesn't add any meaning beyond what the schema provides. It doesn't explain what 'symbol' represents (e.g., a trading pair, user identifier, or asset), its format, or how it relates to fetching the commission rate. With low schema coverage, the description fails to compensate.
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 'Get user's commission rate' clearly states the action (get) and resource (commission rate), but it's vague about what 'user' refers to (e.g., a specific account or symbol) and doesn't distinguish from siblings like 'getAccountInfo' or 'getBalance' that might also retrieve user-related data. It avoids tautology by not just restating the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. Sibling tools like 'getAccountInfo' or 'getBalance' might overlap in retrieving user data, but the description doesn't specify if this is for commission-specific queries or in what context it's preferred. Usage is implied only by the name and description.
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 implies a read-only operation ('Get'), but doesn't specify if it requires authentication, has rate limits, returns real-time or historical data, or what happens on errors. For a financial tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('Get'), but could be slightly improved by adding minimal context to enhance clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial data tools, no annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't explain the return format, error handling, or how the data integrates with other tools like 'setLeverage,' leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('symbol') with 0% description coverage, and the tool description doesn't mention parameters at all. It fails to compensate for the low schema coverage by explaining what 'symbol' represents (e.g., a trading pair like BTCUSDT) or if it's optional. With undocumented parameters, the description adds no value beyond the schema.
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 states the tool retrieves 'notional and leverage brackets,' which clarifies it's a read operation for financial data. However, it's vague about what these brackets represent (e.g., trading limits, margin requirements) and doesn't distinguish it from siblings like 'getAccountInfo' or 'getPositionInfo,' which might overlap in financial data retrieval. It avoids tautology by specifying the data type beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. With siblings like 'getAccountInfo' and 'getPositionInfo' that might offer related financial data, the description lacks context on prerequisites, such as needing a specific symbol or account setup, and doesn't mention exclusions or recommend other tools for different needs.
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 of behavioral disclosure. It only states the action ('Get') without any details on permissions, rate limits, side effects, or response format. For a tool that likely accesses sensitive financial data, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence ('Get current position information.'), which is front-loaded and wastes no words. For a simple tool, this brevity is appropriate, though it may contribute to the lack of detail in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial position data, no annotations, no output schema, and poor parameter coverage, the description is incomplete. It doesn't address what 'current position information' includes (e.g., size, leverage, PnL) or how to interpret results, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('symbol') with 0% description coverage, and the tool description adds no information about this parameter. It doesn't explain what 'symbol' represents (e.g., a trading pair like 'BTCUSDT'), its format, or whether it's optional (as indicated by 0 required parameters), failing to compensate for the schema's lack of documentation.
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 'Get current position information' clearly states the verb ('Get') and resource ('current position information'), making the purpose understandable. However, it doesn't distinguish this tool from similar siblings like 'getPositionMarginHistory' or 'getPositionMode', which also retrieve position-related data, leaving some ambiguity about what specific aspect of positions is targeted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'getBalance', 'getAccountInfo', and other position-related tools, there's no indication of prerequisites, context, 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 provided, so the description carries full burden. It states 'Get trades' which implies a read operation, but doesn't disclose behavioral traits like pagination, rate limits, authentication needs, or what 'trades' includes (e.g., time range, status). This is inadequate for a tool with 5 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence that is front-loaded with the core action. However, it could be more concise by avoiding the vague 'specific account' since 'account' isn't a parameter, and it lacks necessary details for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage, no annotations, no output schema, and multiple sibling tools, the description is incomplete. It fails to explain parameter usage, return values, or how this tool differs from others, making it insufficient for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'account and symbol', but only 'symbol' is a documented parameter; 'account' is not in the schema. It doesn't explain the meaning of parameters like 'endTime', 'startTime', 'limit', or 'fromId', leaving them undocumented.
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 states the verb 'Get' and resource 'trades', but lacks specificity about what 'trades' means in this context (e.g., historical trades, open trades, executed trades). It doesn't distinguish from siblings like 'trades', 'historicalTrades', or 'aggTrades', leaving ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'trades', 'historicalTrades', or 'aggTrades'. The description implies usage for a specific account and symbol, but doesn't clarify prerequisites, exclusions, or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Cancel multiple orders' implies a destructive write operation, but it doesn't disclose critical behavioral traits: whether it requires authentication, rate limits, idempotency, confirmation mechanisms, or what happens on partial failure. For a batch mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action, though it lacks detail due to under-specification rather than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (batch mutation tool), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It fails to explain parameters, behavioral expectations, or output, leaving the agent poorly equipped to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'multiple orders' but doesn't explain the three parameters (orderIdList, origClientOrderIdList, symbol) or their relationships. The agent must guess how to specify which orders to cancel, making this inadequate for a tool with undocumented parameters.
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 'Cancel multiple orders' states the action (cancel) and resource (orders), but it's vague about scope and mechanism. It doesn't distinguish from sibling tools like cancelOrder (single order) or cancelAllOpenOrders (all open orders), leaving ambiguity about whether this cancels specific orders, all orders for a symbol, or something else.
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 cancelOrder or cancelAllOpenOrders. The description doesn't mention prerequisites, constraints, or typical use cases, leaving the agent to infer usage from context 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, so the description carries the full burden of behavioral disclosure. It fails to describe key traits: whether this is a read-only operation, if it requires authentication, potential rate limits, pagination behavior, or the format of returned data. The description is minimal and offers 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, efficient sentence with zero waste. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial API tool with no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on authentication, return format, error handling, and usage context, making it inadequate for an AI agent to reliably invoke this tool in a trading environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the description only mentions 'on a symbol' without explaining what 'symbol' represents (e.g., trading pair format like BTCUSDT), its required status, or any constraints. It adds minimal meaning beyond the schema, insufficiently compensating for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'all open orders on a symbol', making the purpose specific and understandable. It distinguishes from siblings like 'getAllOrders' (which likely includes closed orders) and 'queryOpenOrder' (which might query a single order), though it doesn't explicitly name these 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 like 'getAllOrders' or 'queryOpenOrder'. It lacks context about prerequisites, such as authentication needs or account permissions, and doesn't mention any exclusions or constraints beyond the symbol parameter.
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 it 'gets' data, implying a read-only operation, but doesn't clarify if it requires authentication, has rate limits, returns paginated results, or what the output format is. For a tool with 5 parameters and no output schema, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no wasted words. It's front-loaded with the core purpose, making it easy to scan. However, this conciseness comes at the cost of completeness, as noted in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, 0% schema coverage, no output schema, no annotations), the description is incomplete. It doesn't explain what the tool returns, how to interpret parameters like 'type', or behavioral aspects like error handling. For a financial data tool with multiple inputs, this lack of detail makes it inadequate for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It mentions 'position margin change history', which hints at 'symbol' and possibly 'startTime'/'endTime', but doesn't define 'type' (with enum 1/2), 'limit', or the meaning of 'change history'. This leaves most parameters undocumented, failing to add sufficient meaning beyond the bare schema.
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 'Get position margin change history' clearly states the action (get) and resource (position margin change history), making the purpose understandable. However, it lacks specificity about what 'position margin' refers to (e.g., trading positions) and doesn't distinguish it from sibling tools like 'getPositionInfo' or 'modifyPositionMargin', leaving room for 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 doesn't mention prerequisites, such as needing an active position, or differentiate it from related tools like 'getIncomeHistory' or 'getForceOrders', which might overlap in financial contexts. This absence of context makes it harder for an agent to select the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Check an order's status' implies a read-only operation, but it doesn't specify permissions needed, rate limits, error conditions, or what 'status' entails (e.g., pending, filled, canceled). For a tool with no annotation coverage, this leaves critical behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded and efficiently conveys the core action, though this brevity comes at the cost of missing details needed for full usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return values, parameter usage, or how this tool differs from siblings. For a query tool in a financial context, more context on behavior and output is needed to be fully actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (orderId, origClientOrderId, symbol) are documented in the schema. The description adds no information about these parameters—it doesn't explain what they represent, their formats, or how they interact (e.g., if orderId is optional). This fails to compensate for the lack of schema documentation.
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 'Check an order's status' clearly states the verb ('check') and resource ('order's status'), making the purpose understandable. However, it doesn't distinguish this tool from similar siblings like 'queryOpenOrder' or 'getAllOrders', leaving ambiguity about scope and 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. With siblings like 'queryOpenOrder', 'getAllOrders', and 'getAllOpenOrders', there's no indication of whether this tool checks a single order by ID, filters by symbol, or serves a specific use case, leaving the agent to guess based on parameter names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Change margin type.' implies a mutation operation but doesn't specify permissions required, whether it's reversible, potential risks (e.g., liquidation), rate limits, or response format. This is inadequate for a tool that likely modifies account/trading settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, front-loaded and zero waste. It efficiently communicates the core action without unnecessary words, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutating margin settings), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It fails to address critical aspects like behavioral context, parameter meanings, or expected outcomes, making it insufficient for safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'symbol' represents (e.g., trading pair) or the meaning of 'marginType' values (ISOLATED vs. CROSSED), leaving both parameters semantically unclear beyond the enum list in the schema.
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 'Change margin type.' clearly states the action (change) and resource (margin type), providing a basic purpose. However, it lacks specificity about what margin type refers to (e.g., for trading positions) and doesn't distinguish it from siblings like setLeverage or setPositionMode, which are related but distinct margin/position management 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open position), exclusions, or compare it to siblings like setMultiAssetsMode or modifyPositionMargin, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying it's read-only, but doesn't specify permissions, rate limits, or response format. This leaves gaps for a tool that likely interacts with financial 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 a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 too minimal. It doesn't explain what 'funding rate config' entails (e.g., settings, thresholds) or the return format, leaving the agent with insufficient context to use it effectively in a financial trading environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'symbol' parameter documented as 'Trading symbol'. The description doesn't add any extra meaning beyond this, such as examples or format details, so it meets the baseline for high schema coverage without compensation.
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 'Get funding rate config' clearly states the action ('Get') and resource ('funding rate config'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'fundingRate' (which likely provides current funding rates rather than configuration), leaving some ambiguity about its specific 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. Given sibling tools like 'fundingRate', it's unclear whether this is for retrieving configuration settings versus real-time data, and there are no prerequisites or exclusions 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?
No annotations are provided, so the description carries full burden. 'Modify' implies a write/mutation operation, but it doesn't disclose critical behavioral traits: whether this requires specific permissions, if it's reversible, potential risks (e.g., liquidation if margin is reduced), rate limits, or what happens on success/failure. For a financial trading tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise - a single sentence with no wasted words. It's front-loaded with the core purpose immediately. Every word earns its place, though this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (financial position margin adjustment), no annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't explain what 'isolated position margin' means, the implications of modification, expected outcomes, or error conditions. For a tool that could affect trading positions and risk, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 low at 25% (only 'type' has a description). The description doesn't add any parameter meaning beyond the schema - it doesn't explain what 'symbol', 'amount', 'positionSide', or 'type' represent in context. With low coverage, the description fails to compensate, leaving most parameters semantically unclear. Baseline 3 is generous given the coverage gap.
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 'Modify isolated position margin' states the action (modify) and resource (isolated position margin), but it's vague about what modification entails - it doesn't specify this adjusts collateral/margin for leveraged positions. It distinguishes from siblings like 'setMarginType' or 'setLeverage' by focusing on margin amount adjustment rather than margin configuration, but the distinction isn't explicit.
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 doesn't mention prerequisites (e.g., needing an open isolated position), when not to use it (e.g., for cross margin), or refer to related tools like 'setMarginType' for margin type changes or 'getPositionInfo' to check current margin. Usage is implied by the name but not explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Cancel an active order' implies a destructive mutation, but it doesn't specify permissions required, whether cancellation is reversible, rate limits, error conditions (e.g., if order doesn't exist), or what happens on success (e.g., order status change). This leaves significant gaps 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 extremely concise with a single sentence that front-loads the core purpose. There is no wasted verbiage, making it easy to parse quickly, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive mutation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, parameter meanings, or return values, leaving the agent with insufficient context to use the tool effectively beyond basic inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'orderId', 'origClientOrderId', or 'symbol' represent, their formats, or that 'symbol' is required. For a tool with 3 parameters, this is inadequate, failing to clarify usage beyond the bare 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 action ('Cancel') and target ('an active order'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'cancelAllOpenOrders' or 'cancelBatchOrders', which would require mentioning it cancels individual orders rather than batches or all open orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., order must be active), exclusions (e.g., cannot cancel filled orders), or compare to siblings like 'cancelAllOpenOrders' for bulk operations or 'queryOrder' for checking status first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral information. It states it's a read operation ('Get'), but doesn't disclose pagination behavior, rate limits, authentication requirements, response format, or whether it returns real-time or historical data. For a tool with 5 parameters and no annotation coverage, this is inadequate 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?
Extremely concise single sentence with no wasted words. The description is front-loaded with the core purpose and includes important scope information. Every word earns its place, though the brevity comes at the cost of completeness.
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 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is severely incomplete. It provides basic purpose but lacks parameter documentation, behavioral context, usage guidance, and output information. The conciseness is achieved through under-specification rather than efficient communication.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. The 5 parameters (endTime, limit, orderId, startTime, symbol) are completely undocumented in both schema and description. The description mentions 'all account orders' which implies the 'symbol' parameter might filter by trading pair, but this is only implied, not stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all account orders'), and specifies the scope ('active, canceled, or filled'). It distinguishes from sibling 'getAllOpenOrders' by including all statuses, but doesn't explicitly mention this distinction. The purpose is clear but could be more specific about what makes it different from similar 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 on when to use this tool versus alternatives like 'getAllOpenOrders', 'queryOrder', or 'getTradeList'. The description implies it retrieves all orders regardless of status, but doesn't provide context about when this broad retrieval is appropriate versus more targeted queries. No mention of prerequisites, limitations, or performance considerations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without disclosing behavioral traits like permission requirements, rate limits, side effects (e.g., impact on open positions), or response format. 'Change' implies mutation but lacks critical details for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core purpose. It's appropriately sized for a simple tool, though brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, no output schema, and a mutation tool with 2 parameters, the description is incomplete. It lacks details on behavior, parameters, output, and usage context, making it inadequate for safe and effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter semantics. It doesn't explain what 'symbol' or 'leverage' represent, their formats, or constraints (e.g., leverage range 1-125 from schema). This leaves parameters largely undocumented.
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 ('Change') and target ('user's initial leverage'), which is specific and unambiguous. However, it doesn't differentiate from siblings like 'setMarginType' or 'setMultiAssetsMode' that also modify account settings, leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'setMarginType' or 'modifyPositionMargin', nor any prerequisites or context for leverage changes. The description lacks explicit when/when-not instructions or sibling comparisons.
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 'compressed, aggregate' trades but doesn't explain what this means operationally (e.g., data format, aggregation method, rate limits, or authentication needs). This leaves significant gaps in understanding the tool's behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It's appropriately sized for a tool with well-documented parameters in the schema, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial data tool with 5 parameters and no output schema or annotations, the description is insufficient. It doesn't explain the output format, aggregation details, or error handling, leaving the 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?
Schema description coverage is 100%, so the input schema fully documents all parameters. The description adds no additional meaning beyond the schema, such as explaining relationships between parameters (e.g., 'fromId' vs. time-based filters) or typical use cases. Baseline 3 is appropriate when the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('compressed, aggregate market trades'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'trades' or 'historicalTrades', which likely provide similar trade data in different formats or scopes.
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 'trades' or 'historicalTrades'. The description lacks context about use cases, prerequisites, or comparisons with sibling tools, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Auto-cancel' implies a destructive operation, it doesn't specify whether this requires authentication, has rate limits, what happens to partially filled orders, or if the cancellation is immediate versus scheduled. The description is too minimal 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 extremely concise with just three words, front-loading the core action. Every word earns its place with no wasted verbiage or 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?
For a destructive tool with 2 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'Auto-cancel' means operationally, what the parameters control, or what happens after invocation. The context demands more 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 50% (only 'countdownTime' has a description). The description doesn't mention any parameters, so it adds no semantic value beyond what the schema provides. However, with 2 parameters total and one documented in schema, the baseline 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 ('Auto-cancel') and target ('all open orders'), providing a specific verb+resource combination. However, it doesn't differentiate from the sibling tool 'cancelAllOpenOrders' which appears to serve a similar function, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 like 'cancelAllOpenOrders' or 'cancelBatchOrders'. It lacks context about prerequisites, timing considerations, or any explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves order book data but omits critical details such as rate limits, authentication requirements, data freshness, or pagination behavior. This is inadequate for a tool that likely involves real-time market data access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that efficiently conveys the core functionality without unnecessary words. It is front-loaded with the essential action and resource, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial trading data, lack of annotations, and absence of an output schema, the description is insufficient. It does not explain the return format (e.g., bids/asks arrays), data structure, or any behavioral traits like rate limiting, which are crucial for effective tool use in this domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters ('symbol' and 'limit') with their types and constraints. The description adds no additional semantic context beyond what the schema provides, such as explaining what an order book entails or how 'limit' affects the response, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('order book for a symbol'), making the purpose specific and understandable. However, it does not distinguish this tool from potential siblings like 'ticker_bookTicker' or 'exchangeInfo', which might also provide market data, leaving room for improvement in 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. With siblings like 'ticker_bookTicker' (which might offer bid/ask prices) and 'exchangeInfo' (which could include order book details), there is no indication of context, prerequisites, or exclusions, leaving usage 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets' data (implying a read-only operation) but doesn't mention critical details like rate limits, authentication requirements, error conditions, or the format/structure of the returned history. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It is front-loaded with the core purpose, making it easy to parse quickly. Every word earns its place by conveying essential 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?
Given the complexity of a financial data tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the funding rate history includes (e.g., timestamps, rates), how results are ordered, or any behavioral traits like pagination or default time ranges. This leaves the agent under-informed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all four parameters (endTime, limit, startTime, symbol) with units and constraints. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get funding rate history' clearly states the verb ('Get') and resource ('funding rate history'), making the purpose immediately understandable. It distinguishes from many siblings like 'fundingInfo' (which might provide current rates) by specifying 'history', though it doesn't explicitly contrast with all 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 like 'fundingInfo' or other market data tools. It lacks context about prerequisites, typical use cases, or any 'when-not-to-use' scenarios, 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.
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 it's a read operation ('Get'), implying it's non-destructive, but doesn't cover critical aspects like authentication requirements, rate limits, error conditions, or what the return data looks like (e.g., hedging vs. one-way mode). This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse, which is ideal for a simple tool like this.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a read operation with no parameters but likely requiring authentication) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'position mode' entails (e.g., its values or implications), how the data is returned, or any behavioral constraints, leaving the agent under-informed for proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline expectation. No additional value is required or provided beyond the empty schema.
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 'Get user's position mode' clearly states the verb ('Get') and resource ('user's position mode'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'setPositionMode' or explain what 'position mode' means in this context, leaving some ambiguity about the specific 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. It doesn't mention prerequisites (e.g., authentication), when it's appropriate (e.g., before trading), or differentiate it from similar tools like 'getPositionInfo' or 'setPositionMode', leaving the agent 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.
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 'older' trades, implying a focus on past data, but fails to detail critical aspects like rate limits, authentication requirements, pagination behavior, or error handling. This is inadequate for a tool that likely interacts with market 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 a single, efficient sentence with no wasted words. It's front-loaded and directly states the tool's function, making it easy to parse quickly 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 and output schema, the description is incomplete. It doesn't explain what 'older' entails, how results are returned, or any prerequisites for use. For a tool with three parameters and no structured behavioral hints, more context is needed to ensure proper agent 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%, with clear documentation for 'fromId', 'limit', and 'symbol' parameters. The description adds no additional meaning beyond the schema, such as explaining what 'older' means in relation to 'fromId' or default behaviors. This meets the baseline score since the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get older market historical trades' clearly states the verb ('Get') and resource ('older market historical trades'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'trades' or 'getTradeList', which likely also retrieve trade data, leaving some ambiguity about its specific 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. With sibling tools such as 'trades' and 'getTradeList' present, there's no indication of what makes 'historicalTrades' unique—whether it's for archived data, different timeframes, or other criteria—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 provided, so the description carries full burden. It mentions the data type (kline/candlestick bars) but lacks critical behavioral details: it doesn't specify if this is a read-only operation, the format/units of returned data, pagination behavior (limit parameter hints at this but not explicitly), rate limits, authentication needs, or error conditions. The description is minimal and misses key operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Kline/candlestick bars for the index price of a pair'). There is zero wasted text, making it highly concise and well-structured for quick understanding.
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, no output schema, and 5 parameters (though well-described in schema), the description is incomplete. It lacks behavioral transparency (e.g., read-only status, data format), usage guidelines versus siblings, and output details. For a data retrieval tool with multiple similar alternatives, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters (pair, interval, startTime, endTime, limit) with descriptions. The description adds no additional parameter semantics beyond implying 'index price' context for the pair. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'Kline/candlestick bars for the index price of a pair,' specifying the verb (retrieves/gets) and resource (index price klines). It distinguishes from sibling 'klines' (likely spot price) and 'markPriceKlines' by specifying 'index price,' but doesn't explicitly contrast with these siblings in the description text.
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 'klines' or 'markPriceKlines.' The description implies it's for index price data, but doesn't state when index price is preferred over spot or mark price, or mention 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 of behavioral disclosure. It states the tool 'gets' data, implying a read-only operation, but doesn't mention any behavioral traits like rate limits, authentication requirements, data freshness, or error conditions. For a financial data tool with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a straightforward data retrieval tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial data retrieval, lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the returned candlestick bars contain (e.g., OHLCV data), how results are structured, or any limitations beyond what's implied by parameters. For a tool with 5 parameters in this domain, more 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?
The description doesn't add any parameter semantics beyond what's already in the input schema, which has 100% coverage with clear descriptions for all 5 parameters. The baseline score of 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate with additional context like parameter interactions or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('Kline/candlestick bars for a symbol'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'indexPriceKlines' or 'markPriceKlines', which appear to serve similar functions for different data types, leaving some ambiguity about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'indexPriceKlines' and 'markPriceKlines' that seem related, there's no indication of what distinguishes this tool (e.g., regular market data vs. index or mark price data). No context 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but lacks behavioral details. It doesn't disclose if this is a read-only operation, rate limits, authentication needs, or response format. The description is minimal and doesn't add meaningful context beyond the basic purpose, leaving gaps for a tool with parameters.
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 with zero waste. It's front-loaded and appropriately sized, making it easy to parse 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 no annotations, no output schema, and a tool with 5 parameters, the description is incomplete. It lacks details on behavior, return values, or usage context, making it inadequate for an agent to fully understand how to invoke and interpret results 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 description coverage is 100%, so the schema fully documents parameters like 'endTime' and 'interval.' The description adds no additional meaning beyond implying 'symbol' and 'interval' are key, which is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'Kline/candlestick bars for the mark price of a symbol,' specifying the verb (retrieve) and resource (mark price klines). It distinguishes from sibling tools like 'klines' (likely regular price) and 'indexPriceKlines' by specifying 'mark price,' though it doesn't explicitly contrast 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 on when to use this tool versus alternatives like 'klines' or 'indexPriceKlines.' The description implies it's for mark price data but doesn't specify use cases, prerequisites, or exclusions, leaving the agent to infer context from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a mutation ('Change'), suggesting it's not read-only, but doesn't disclose behavioral traits like required permissions, side effects (e.g., impact on open positions), rate limits, or error conditions. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Change user's Multi-Assets mode.') that is front-loaded and wastes no words. It's appropriately sized for the tool's simple 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?
Given the tool's complexity (a mutation with no annotations and no output schema), the description is incomplete. It doesn't explain what Multi-Assets mode is, the implications of changing it, or what the tool returns. With no output schema, the description should at least hint at the response, but it doesn't, leaving significant 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 input schema has 100% description coverage, with the parameter 'multiAssetsMargin' clearly documented as a string with values 'true' for Multi-Assets Mode and 'false' for Single-Asset Mode. The description doesn't add meaning beyond this, but with high schema coverage and only one parameter, a baseline of 4 is appropriate as the schema fully compensates.
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 'Change user's Multi-Assets mode' clearly states the action (change) and target (user's Multi-Assets mode), but it's vague about what Multi-Assets mode entails and doesn't distinguish from sibling tools like 'getMultiAssetsMode' (which presumably reads the mode) or 'setPositionMode' (which might be related). It avoids tautology but lacks 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), context (e.g., after checking current mode with getMultiAssetsMode), or exclusions (e.g., not for single-asset accounts). The description alone offers no usage instructions.
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 indicates a mutation ('Change'), implying potential side effects, but does not specify required permissions, rate limits, confirmation prompts, or error conditions. This leaves significant gaps for a tool that modifies user settings.
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 directly states the tool's purpose without redundancy or unnecessary details. It is front-loaded and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral aspects (e.g., safety, permissions), expected outcomes, or error handling, leaving the agent with incomplete context for proper 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 description coverage is 100%, fully documenting the single parameter 'dualSidePosition' with its values. The description adds no additional parameter semantics beyond what the schema provides, such as examples or edge cases, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Change') and resource ('user's position mode'), specifying the two modes (Hedge Mode or One-way Mode). It distinguishes from siblings like 'getPositionMode' (which retrieves rather than changes) and 'setLeverage' (which adjusts leverage, not position mode), but does not explicitly contrast with all siblings.
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 prerequisites (e.g., account permissions), timing considerations, or related tools like 'setMultiAssetsMode'. It only states what the tool does, not when it should be applied.
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 'price change statistics' but fails to detail aspects like whether this is a read-only operation, potential rate limits, authentication needs, or the format of returned data. This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy to understand quickly, which aligns well with best practices for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (providing statistics over a rolling window) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what specific statistics are returned (e.g., high, low, volume), how the rolling window works, or error handling, leaving the agent with insufficient 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 input schema has 100% description coverage, with the 'symbol' parameter documented as 'Trading symbol.' The description adds no additional meaning beyond this, such as examples or constraints. Since the schema handles the parameter documentation adequately, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as providing '24 hour rolling window price change statistics,' which is a specific verb+resource combination. However, it doesn't explicitly distinguish this from sibling tools like 'ticker_price' or 'ticker_bookTicker,' which might also provide price-related data, leaving some ambiguity about its 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 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 'ticker_price' or 'ticker_bookTicker.' It lacks context about scenarios where 24-hour statistics are preferred over other price or ticker data, providing no usage instructions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieving 'latest price' but doesn't specify whether this is real-time or delayed data, any rate limits, authentication requirements, or error handling. For a financial data tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's function without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial data tools and the lack of annotations or output schema, the description is incomplete. It doesn't cover return values, data formats, potential errors, or how it differs from similar tools. For a tool in a server with many siblings, more context is needed to ensure proper 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 has 100% description coverage, with the 'symbol' parameter documented as 'Trading symbol'. The description adds minimal value by implying it can handle 'symbol or symbols' (plural), but doesn't clarify if multiple symbols are supported via a list or array format. Baseline 3 is appropriate as the schema does most of the work.
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 as retrieving the 'latest price' for a 'symbol or symbols', specifying both the action and resource. However, it doesn't explicitly differentiate from sibling tools like 'ticker_24hr' or 'ticker_bookTicker', which likely provide different price-related data, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to trading and market data (e.g., 'ticker_24hr', 'depth', 'klines'), there is no indication of specific contexts, prerequisites, or exclusions for using 'ticker_price'.
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. 'Get recent market trades' implies a read operation but doesn't specify whether this requires authentication, has rate limits, returns real-time or delayed data, or what format the trades come in. For a financial data tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple data retrieval tool and front-loads the essential 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?
For a financial market data tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'recent' means (timeframe), what data fields are returned, whether authentication is required, or how this differs from similar sibling tools. The context demands more 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%, with both parameters ('limit' and 'symbol') well-documented in the schema. The description doesn't add any parameter information beyond what's already in the schema, so it meets the baseline for high schema coverage but doesn't provide additional 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 'Get recent market trades' clearly states the verb ('Get') and resource ('recent market trades'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'historicalTrades' or 'getTradeList', which appear to serve similar functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools that might retrieve trade data (historicalTrades, getTradeList, aggTrades), there's no indication of what makes 'trades' distinct or when it 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Cancel') but doesn't mention critical details such as whether this is irreversible, requires specific permissions, has rate limits, or what happens if no open orders exist. This leaves significant gaps 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, direct sentence with no unnecessary words, making it highly concise and front-loaded. Every part of the sentence contributes essential information about the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a cancellation tool with no annotations, no output schema, and low schema coverage, the description is inadequate. It doesn't cover behavioral aspects like side effects, error conditions, or return values, making it incomplete for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by specifying that the 'symbol' parameter is used to target orders on a particular symbol, which is helpful given the 0% schema description coverage. However, it doesn't explain the format or constraints of the 'symbol' (e.g., trading pair like 'BTCUSDT'), so it doesn't fully compensate for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cancel all open orders') and the target resource ('on a symbol'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'cancelOrder' or 'cancelBatchOrders', which handle individual or batch cancellations, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'cancelOrder' for single orders or 'cancelBatchOrders' for specific batches. It also lacks information on prerequisites, like whether the user must have open orders on the symbol, 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 implies a read-only operation ('Get') but doesn't specify permissions, rate limits, or response format. This is inadequate for a tool in a financial context where such details are 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 a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial tools and lack of annotations or output schema, the description is incomplete. It doesn't explain what 'account information' includes or how it differs from other account-related tools, leaving gaps in understanding for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is acceptable here, earning a baseline score above 3 due to the lack of 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 verb ('Get') and resource ('current account information'), making the purpose understandable. However, it doesn't differentiate from siblings like 'getBalance' or 'getCommissionRate', which might also retrieve account-related data, leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'getBalance' or 'getCommissionRate'. The description lacks context about prerequisites, timing, or exclusions, offering minimal help for selection among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Get'), but doesn't specify authentication requirements, rate limits, error conditions, or the format of the returned balance. For a financial tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by directly contributing to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial data and the absence of both annotations and an output schema, the description is insufficient. It doesn't explain what the balance includes (e.g., total, available, margin), the currency or asset format, or any behavioral traits like permissions needed. For a tool in this context, more detail is required to be 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 tool has 0 parameters, and the schema description coverage is 100%, so there is no need for parameter details in the description. The baseline for this scenario is 4, as the description appropriately avoids redundant information while clearly stating the tool's purpose.
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 futures account balance' clearly states the verb ('Get') and resource ('futures account balance'), making the purpose immediately understandable. It distinguishes itself from siblings like 'getAccountInfo' or 'getPositionInfo' by specifying the balance aspect of futures accounts. However, it doesn't explicitly contrast with these alternatives, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 like 'getAccountInfo' or 'getPositionInfo', which might also contain balance-related data. There is no mention of prerequisites, context, or exclusions, 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.
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 it 'gets' information, implying a read-only operation, but doesn't specify authentication requirements, rate limits, error conditions, or what the return value looks like (e.g., a boolean or detailed object). This leaves significant gaps for a tool in a financial/trading 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, efficient sentence with no wasted words. It's front-loaded with the core action ('Get') and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial/trading tools and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'Multi-Assets mode' means (e.g., a setting for cross-margin or isolated margin), what the return value includes, or any behavioral traits like error handling. This is inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, so it meets the baseline. No additional parameter semantics are required or 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 verb 'Get' and the resource 'user's Multi-Assets mode', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'setMultiAssetsMode' (which sets the mode) or explain what 'Multi-Assets mode' entails in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), when it's appropriate (e.g., checking current settings), or refer to related tools like 'setMultiAssetsMode' for modification.
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 tool tests connectivity but doesn't describe what 'testing' entails—whether it returns a simple success/failure, latency metrics, error details, or requires authentication. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema), the description is minimal but inadequate. It doesn't explain what the test returns or how to interpret results, which is crucial for connectivity testing. With no annotations and low complexity, more detail is needed to be 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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, which is appropriate, but it doesn't fully compensate for other gaps, so it scores just below the maximum.
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 as testing connectivity to the Rest API, which is a specific action (test) on a resource (Rest API). However, it doesn't distinguish itself from potential sibling tools like 'time' that might also test connectivity, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. In a context with many sibling tools, it doesn't specify if this is for initial setup, troubleshooting, or as a prerequisite for other operations, leaving the agent without clear 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets' data, implying a read-only operation, but doesn't specify whether it requires authentication, has rate limits, returns real-time or historical data, or handles errors. This leaves significant gaps in understanding how the tool behaves beyond its 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 extremely concise with just one sentence, front-loading the core purpose without any wasted words. Every part of the sentence directly contributes to understanding what the tool does, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and no output schema, the description is minimally adequate. It states what data is retrieved but lacks details on return format, error handling, or behavioral traits. Without annotations or output schema, more context would be helpful, but it's not critically incomplete given the tool's apparent 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 has 100% description coverage, with the 'symbol' parameter documented as 'Trading symbol'. The description adds no additional meaning beyond this, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately 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's purpose with specific verbs ('Get') and resources ('Mark Price and Funding Rate'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'fundingRate' or 'markPriceKlines', which might offer overlapping functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'fundingRate' and 'markPriceKlines' present, there's no indication of context, prerequisites, or exclusions, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves best price/quantity, implying a read-only operation, but doesn't specify whether it's real-time or cached, any rate limits, authentication requirements, or error conditions. For a financial data tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded with the core functionality, making it easy to parse quickly. Every word earns its place, and there's no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It explains what the tool returns but lacks details on behavior, usage context, or output format. In a server with many trading tools, more guidance would help, but for a simple query tool, it's passable though 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?
The description mentions 'a symbol or symbols,' which aligns with the single 'symbol' parameter in the input schema. Since schema description coverage is 100% (the parameter is well-documented as 'Trading symbol'), the description adds minimal value beyond the schema. It doesn't provide additional details like format examples or multi-symbol handling, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving 'Best price/qty on the order book for a symbol or symbols.' It specifies the action (retrieving best price/quantity) and resource (order book for symbols), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'depth' (which might provide full order book depth) or 'ticker_price' (which might give current price without quantity), so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, such as when to prefer 'depth' for full order book data or 'ticker_price' for price-only information. With many sibling tools in this trading context, the lack of usage guidelines leaves the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't specify if it requires authentication, has rate limits, returns real-time or cached data, or details the response format. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get current exchange trading rules and symbol information') with zero wasted words. Every part of the sentence earns its place by clearly conveying 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 has 0 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It explains what the tool does but lacks details on behavioral aspects (e.g., authentication needs, data format) that would be helpful for an agent, especially without annotations. This makes it complete enough for basic use but with clear 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 0 parameters, and the schema description coverage is 100%, so there's no need for parameter details in the description. The description doesn't add any parameter information, which is appropriate here, but it doesn't explicitly state 'no parameters required,' so it doesn't achieve a perfect score.
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 with a specific verb ('Get') and resource ('current exchange trading rules and symbol information'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'getAccountInfo' or 'getBalance', which could also provide informational data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (e.g., 'getAccountInfo', 'getBalance'), there's no indication of context, prerequisites, or exclusions, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool gets time but does not specify if it requires authentication, rate limits, or what format the time is returned in (e.g., UTC, timestamp). This leaves gaps in understanding the tool's behavior 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, clear sentence with no wasted words, front-loading the core purpose. It is appropriately sized for a simple tool and efficiently communicates the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose but lacks details on return format or behavioral traits, which could be helpful for an agent to use it correctly in context with 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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter details, which is appropriate here, but it could mention if any implicit parameters (like timezone) are involved, though not required for a high score given the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('current server time'), with no ambiguity. It directly answers what the tool does without restating the name or title, making it immediately understandable.
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 time, but does not explicitly state when to use this tool versus alternatives (e.g., system time functions or other time-related tools). No exclusions or prerequisites are mentioned, leaving usage context inferred rather than defined.
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:

[![aster-mcp-server MCP server](https://glama.ai/mcp/servers/questflowai/aster-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/questflowai/aster-mcp-server)

Score Badge

Copy to your README.md:

[![aster-mcp-server MCP server](https://glama.ai/mcp/servers/questflowai/aster-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/questflowai/aster-mcp-server)

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/questflowai/aster-mcp-server'

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