Bybit MCP Server

Official

by bybit-exchange

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v2.1.18
Disambiguation3/5
While each tool has a detailed description, the sheer volume (343 tools) creates ambiguity. Many tools relate to similar concepts (e.g., different loan types, multiple order history endpoints), making it difficult for an agent to quickly select the correct one without careful reading. Overlap exists, especially among query and history tools.
Naming Consistency4/5
The naming generally follows a consistent verb_noun pattern (e.g., getAccountInfo, createOrder, cancelAllOrders). Minor inconsistencies exist, such as the inclusion of 'V5' suffixes (listSubAPIKeysV5) and a few tools with different conventions (listSubscriptions), but overall the pattern is predictable.
Tool Count1/5
343 tools is far too many for a single server. This vastly exceeds the typical 3-15 well-scoped tools. The server attempts to cover all Bybit API endpoints, resulting in an overwhelming surface that is difficult to navigate and suggests the need for splitting into multiple specialized servers per domain (e.g., trading, earn, P2P).
Completeness5/5
The tool set is remarkably comprehensive, covering virtually every aspect of the Bybit platform: trading (spot, futures, options), earn products, copy trading, RFQ, P2P, crypto loans, asset management, WebSocket subscriptions, and more. There are no obvious gaps for the stated purpose of a full exchange API.
Average 3.8/5 across 343 of 343 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on August 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description lacks any behavioral traits (e.g., idempotency, side effects, rate limits). As a query tool, it likely is read-only, but this is not stated.
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?
Single sentence, concise but too brief. It could include key details without losing conciseness, but it is not 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?
With 5 undocumented parameters, no output schema, and many related sibling tools, the description is severely incomplete. Fails to provide enough context for correct 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?
5 parameters (orderCurrency, term, orderBy, sort, limit) have no descriptions in schema (0% coverage). Description adds no explanation of their meaning or format, leaving the agent without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Query available borrow orders (demand)' but tool name includes 'FixedSupplyOrderQuote', creating confusion. It does not clearly distinguish from sibling 'getCryptoLoanFixedBorrowOrderQuote' which likely handles borrowing quotes. Purpose is unclear.
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 'getCryptoLoanFixedBorrowOrderQuote' or other query tools. No context for scenarios 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 present, so the description must fully convey behavioral traits. It fails to disclose any: no information on whether subscriptions are persistent, how multiple subscriptions are handled, rate limits, or what happens after a message is received. The behavioral model is completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise but under-specified. It sacrifices necessary detail for brevity. Proper conciseness would still include key behavioral and param info. This is more omission than efficiency.
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 presence of many sibling subscription tools, 4 parameters with no schema descriptions, and no annotations, the description is critically incomplete. An AI agent cannot determine the tool's exact function, proper invocation, or expected behavior without additional information.
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 the input schema provides no parameter descriptions. The tool description does not compensate; it does not explain what 'symbol', 'category', 'messageCount', or 'timeoutMs' mean. The only hint is that 'category' defaults to 'linear', but the purpose of these parameters remains unclear.
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 '订阅价格限制推送' (Subscribe to price limit push) indicates the verb (subscribe) and resource (price limit push), but it is vague and does not distinguish this tool from many similar sibling subscription tools like subscribeTickers or subscribeOrderbook. The purpose is implied but lacks specificity about what constitutes a 'price limit push'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not explain when to use this tool versus alternatives such as subscribePriceAlert or other subscriptions. There is no mention of scenarios, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states the function without explaining how subscription works, whether it is continuous, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence) but lacks structure. It does not organize information or highlight key points, and the Chinese may not be accessible to all users.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal for a subscription tool with two parameters and no output schema. It omits context about the subscription lifecycle, data format, and parameter defaults, leaving the agent underinformed.
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 description does not mention any parameters. With 0% schema description coverage, it fails to clarify the meaning of messageCount and timeoutMs, which the schema partially defines but without 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 '订阅 Spread 成交数据' clearly indicates that the tool subscribes to Spread trade data. It distinguishes from sibling tools like subscribePublicTrade and subscribeRfqPublicTrades by specifying 'Spread', but does not elaborate further.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as whether the subscription is continuous, how to manage the subscription lifecycle, data delivery frequency, or limitations. The agent has no information about side effects or requirements.
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 short (one sentence), which is concise but at the expense of crucial information. It does not earn its place by providing meaningful content beyond the tool's name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 5 parameters, no annotations, no output schema, and many sibling subscription tools, the description is severely incomplete. It lacks essential details about subscription behavior, parameter usage, and how to stop the subscription, making it inadequate for an AI agent to invoke correctly.
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 and no parameter explanations in the description, the agent has no understanding of the meaning of 'interval', 'symbol', 'category', 'messageCount', or 'timeoutMs'. The description adds no value beyond the schema's structural definition.
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 '订阅 K 线推送' clearly indicates that the tool subscribes to K-line (candlestick) push data. This distinguishes it from sibling subscription tools like subscribeOrderbook or subscribeTickers, but it does not specify the exact resource (e.g., market K-line vs. index price K-line) or provide additional context 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 such as getMarketKline for polling or other subscription tools. The description lacks explicit context for when a subscription is appropriate or how it differs from one-time data retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits. It does not explain what subscribing entails (e.g., long-lived stream, message delivery behavior, cleanup, side effects).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 Chinese characters), but this brevity sacrifices necessary detail. It is efficient but insufficient, lacking any structure or additional information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no parameter explanations, and no usage guidance, the description is severely incomplete. It does not provide enough context for an AI agent to correctly invoke the tool.
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%, and the description does not mention parameters. The two parameters (messageCount, timeoutMs) are left completely unexplained, offering no value beyond the raw 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 '订阅 Spread 订单薄' clearly states the tool subscribes to a spread orderbook, indicating a specific resource. However, it does not differentiate from sibling tools like 'subscribeOrderbook' or 'subscribeSpreadOrder', which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks any context about the appropriate scenarios or distinctions from siblings such as 'subscribeSpreadPublicTrade' or 'subscribeSpreadTickers'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as subscription lifecycle, data delivery mode, authentication requirements, or rate limits. The agent has no insight into side effects or persistence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It could be front-loaded with key info but provides minimal content for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and two undocumented parameters, the description is vastly incomplete. It omits subscription behavior, return format, and operational details needed for correct 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 description adds no meaning to the parameters (messageCount, timeoutMs). Schema description coverage is 0%, and the text does not explain their purpose, formatting, or effect, requiring the agent to guess.
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 'Subscribe to Spread market snapshot' clearly indicates the tool subscribes to spread ticker data, distinguishing it from sibling subscription tools like subscribeSpreadOrderbook and subscribeSpreadPublicTrade. However, it lacks specificity on what data fields are included in the snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention use cases, conditions, or exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description merely says 'execute', implying mutation. No details on effects, reversibility, or required permissions are provided. The description adds minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded. It is concise but lacks structure and detail; still, it is not 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 complexity (financial action with many sibling repayment tools) and lack of output schema, the description is grossly incomplete. It fails to explain what 'quick repayment' entails, how it differs from alternatives, or what the result is.
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 should explain the 'coin' parameter. It only says 'specified coin', which adds no meaning beyond the schema's 'coin' property. No format or valid values are given.
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 action ('execute quick repayment') and resource ('specified coin'), but does not differentiate from sibling tools like accountRepay, accountNoConvertRepay, or postCryptoLoanFixedFullyRepay. It is clear but lacks specificity to distinguish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many other repayment tools. The description gives no context for selection or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states 'subscribe' but does not describe the subscription behavior (e.g., push vs. poll, duration, how to stop, data format). This is insufficient for a subscription tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is under-specified rather than concise. It lacks the detail needed to be useful.
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 subscription tool with three parameters and no output schema, the description provides almost no context. It fails to explain what the subscription returns, how the parameters affect behavior, or any operational aspects.
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 no parameter descriptions exist in the schema. The description adds no explanation for any of the three parameters ('coin', 'messageCount', 'timeoutMs'). This is a critical gap.
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 '订阅保险基金数据' translates to 'subscribe to insurance fund data', which clearly identifies the operation (subscribe) and resource (insurance fund data). However, among the many sibling subscription tools (e.g., subscribeAdlAlert, subscribeDcp), it does not differentiate what 'insurance fund data' specifically entails, reducing clarity in 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?
No guidance on when to use this tool versus the many other subscription tools. No mention of prerequisites, typical use cases, or conditions for subscribing.
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?
The description lacks any disclosure of behavioral traits such as subscription duration, how to manage subscriptions, or what the output contains. Without annotations, the description should provide safety or side-effect information, but it does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (4 characters) but fails to provide necessary context. Conciseness should not sacrifice completeness; here, critical information is missing.
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 (4 parameters, no output schema, many sibling subscription tools), the description is severely incomplete. It does not cover return values, subscription lifecycle, or how to interpret results.
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, the description should explain parameters like symbol, category, etc. It adds no value beyond the parameter names and types, leaving the agent without guidance on required values.
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 'Subscribe to liquidation data' clearly states the verb (subscribe) and resource (liquidation data). It is specific enough to distinguish from many unrelated tools, but it does not differentiate from other subscription tools like subscribeAdlAlert or subscribeExecution.
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 subscribeAdlAlert or subscribePosition. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It only mentions 'real-time updates' but omits key details like whether it returns a subscription ID, message format, lifecycle, concurrency limits, or how to stop the subscription.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified for a tool with three optional parameters and no parameter descriptions. It sacrifices essential details for brevity.
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 subscription tool with no output schema and zero parameter coverage, the description is critically incomplete. It fails to explain behavior, return values, or parameter semantics, leaving the agent without sufficient guidance.
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%; the description adds no explanations for parameters like 'category', 'messageCount', or 'timeoutMs'. The agent cannot infer their meaning or constraints from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('subscribe') and resource ('real-time order status updates for your account'), making the purpose understandable. However, it does not explicitly differentiate from siblings like subscribeExecution or subscribePosition, which could overlap.
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 (e.g., polling getOrderList or other subscribe tools). The agent is left to infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the purpose without any behavioral details. It does not disclose whether the subscription is persistent, how data is delivered, or any side effects. The agent receives zero behavioral insight beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Chinese, with no fluff. It is front-loaded in the sense that it directly states the purpose. However, it could be structured more informatively.
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 (4 parameters, subscription behavior, no output schema, and no annotations), the description is severely incomplete. It lacks details on return values, usage patterns, and behavioral context, leaving the agent without enough information.
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 4 parameters with 0% description coverage, and the description does not add any meaning to parameters like symbol, category, messageCount, or timeoutMs. The agent gets no help understanding what these parameters do.
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 indicates the tool subscribes to real-time trade data. It is not a tautology and provides specific verb+resource. However, it does not differentiate from similar siblings like subscribeRfqPublicTrades or subscribeSpreadPublicTrade, lacking distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as getPublicTrades or other subscribe tools. It does not specify context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states the tool is a query (safe read) and includes permission/rate limit info, but omits details on pagination, response structure, or what 'order history' entails (e.g., only advance earn orders).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load purpose and add essential constraints (permission, rate limit). However, the brevity sacrifices necessary detail for a tool with many parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, 8 parameters with 0% schema coverage, and many sibling tools, the description is critically incomplete. It fails to explain tool behavior, parameter meanings, or return value, making it hard for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 8 parameters (category, productId, orderId, etc.). This forces the agent to infer meaning from names alone, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries order history, but does not distinguish it from sibling tools like getOrderHistory or getEarnOrderHistory. The name includes 'AdvanceEarn' which implies specialization, but the description does not leverage this to clarify 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 vs alternatives. The description mentions required Earn permission and rate limit, but does not specify contexts (e.g., filtering by category or pagination).
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?
Discloses default 90-day range and 180-day maximum, which is valuable. However, with no annotations and 0% schema coverage, the description fails to mention important behavior like pagination (page/size are required), ordering, or output structure, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that front-load the core action. However, it could be more structured to include parameter hints without becoming 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 7 parameters, no output schema, and many sibling order-list tools, the description is notably incomplete. It lacks parameter guidance, pagination details, differentiation from similar tools, and output format, leaving the agent with insufficient information to use the tool effectively.
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%, yet the description does not explain any of the 7 parameters. It only implies time-range parameters through the default mention, but required page/size and other filters (status, tokenId, side) are completely 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 it retrieves a list of P2P orders with a verb and resource. It specifies default and maximum time ranges, which adds context, but does not explicitly differentiate from sibling tools like getOrderList or getOrderHistory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description only states what it does without providing context for selection among many similar order-listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states it's a query (likely read-only) and includes a rate limit. It does not address authentication, side effects, or safety. The rate limit is useful but insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences: one stating purpose and one for rate limit. It front-loads the purpose efficiently, though it may be too sparse.
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 6 parameters, no output schema, and no annotations, the description is severely incomplete. It lacks any details about parameter usage, response format, or constraints beyond rate limit. This is inadequate for a tool with such complexity.
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 schema has 0% description coverage for 6 parameters, and the description does not explain any parameter meanings, formats, or optionality. This leaves the agent unable to use the tool correctly without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Query') and the resource ('active borrow contracts (loans)'). However, it does not differentiate from similar sibling tools like 'queryFixedBorrowContracts' or 'getCryptoLoanFixedBorrowOrderInfo', 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?
No guidance is provided on when to use this tool versus alternatives. The mention of rate limit is behavioral, not usage guidance. There is no explicit 'when-to-use' or 'when-not-to-use' 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?
The only behavioral detail provided is a rate limit of 5 requests per UID. With no annotations, the description fails to disclose pagination, ordering, or other important behavior such as default response format or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with the rate limit front-loaded. However, it is so minimal that it sacrifices necessary information, making it less useful despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, no output schema, and many sibling tools, the description is incomplete. It does not explain how to use parameters like cursor for pagination or what the output structure looks like, limiting an agent's ability to invoke it correctly.
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?
None of the four parameters (repayId, loanCurrency, limit, cursor) are explained in the description. Schema coverage is 0%, and the description adds no meaning beyond the parameter names.
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 tool name and description clearly indicate it queries loan repayment records. However, it does not differentiate between fixed and flexible loan types, missing a chance to distinguish from the sibling tool getCryptoLoanFlexibleRepaymentHistory.
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 getCryptoLoanFlexibleRepaymentHistory or other loan history tools. No context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only mentions rate limit (5 requests/UID). No disclosure of read-only nature, authentication needs, or error handling. Given no annotations, description should provide more behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded. However, it is under-specified for a 6-parameter tool; brevity does not compensate for missing 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 no output schema, no parameter descriptions, and no annotations, the description is insufficient. Fails to explain return values, parameter dependencies, or use cases.
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?
Six parameters (orderId, orderCurrency, state, term, limit, cursor) with 0% schema description coverage. Description adds no explanation of parameter usage, format, or constraints.
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?
States 'Query supply (lending) order details and history' with clear verb ('Query') and resource ('supply order details and history'). While distinct from siblings like getCryptoLoanFixedSupplyOrderQuote, it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., getCryptoLoanFixedSupplyContractInfo). Does not specify prerequisites or context for use.
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 provided, so description must compensate. It only mentions a rate limit of 10 req/s but does not disclose other behavioral traits such as whether it is a read-only operation, what data is returned, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it lacks critical information. While brevity is appreciated, it is under-specified for effective tool usage.
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 three undocumented parameters and no output schema, the description is insufficient. It does not explain parameter meanings, return format, or use cases, making it hard for an AI agent to invoke correctly.
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 schema has three parameters (productId, category, coin) with zero description coverage. The tool description does not mention or explain any parameter, leaving the agent without guidance on how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Query current fixed term position information,' which clearly indicates the tool retrieves fixed-term position data. However, it does not differentiate from sibling tools like getFixedTermOrder or getFixedTermProduct, which could be confused.
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. There are many related tools (e.g., getFixedTermOrder, placeFixedTermOrder), but the description provides no context for selection.
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 provided, and the description lacks any behavioral details such as authentication requirements, rate limits, or whether it returns active ads only. It does not compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (8 words) but at the cost of missing critical details. It is front-loaded but does not earn its place as it provides only the basic purpose.
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 7 parameters, no output schema, and no annotations, the description is wholly inadequate. It fails to explain parameter usage, response format, or pagination, making it incomplete 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?
Schema coverage is 0% with 7 undocumented parameters. The description adds no information about parameter meaning, formats, or defaults, leaving the agent with no guidance beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'list of my P2P advertisements', which distinguishes it from siblings like 'getAds' (general) and 'getMyAdDetails' (single ad).
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 'getAds' or 'getMyAdDetails'. No exclusions or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only discloses rate limit, not read-only nature, authentication, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no clutter, but lacks structure (e.g., parameter details or usage examples).
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?
No output schema, no parameter docs, no return value description. Incomplete for a 5-parameter tool with pagination.
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 coverage is 0% and description provides no parameter explanations. Agents lack meaning for coin, time range, pagination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries hourly yield records. While similar tools exist (e.g., getTokenDailyYield), the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like getEarnHourlyYieldHistory. Only mentions rate limit.
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 provided. The description only states the action without any behavioral details such as side effects, required permissions, or what happens after creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (5 words), which is concise but lacks necessary detail. It is structured as a single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 required parameters, nested objects, many siblings, no output schema), the description is severely inadequate. No information on return values, usage context, or parameter dependencies.
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%. The description adds no meaning beyond the parameter names. All 14 parameters are required but unexplained, including nested objects and enums.
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 'Create a new P2P advertisement' clearly states the verb and resource. It distinguishes from siblings like 'updateAd' and 'removeAd', but could be more specific about what a P2P advertisement is.
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. No mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only mentions a rate limit (1 request per UID), but omits side effects, permissions, reversibility, or the impact on loan status. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, which is concise, but it is under-specified for a 4-parameter tool. It is not verbose, but lacks necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 required parameters, no output schema, many siblings), the description fails to explain parameters, differentiate from similar tools, or disclose behavioral aspects beyond rate limit. It is incomplete.
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%, and the description provides no explanation of the 4 required parameters (loanId, loanCurrency, collateralCoin, amount). The agent has no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Repay loan by converting collateral to loan currency' which is a specific verb and resource, but it does not explicitly differentiate from sibling tools like postCryptoLoanFixedFullyRepay or postCryptoLoanFlexibleRepay, leaving ambiguity about the fixed vs flexible 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?
No guidance on when to use this tool vs alternatives. With many sibling repay tools, the description should provide context on when converting collateral is appropriate, but it offers none.
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?
Without annotations, the description fails to disclose behavioral traits such as subscription duration, update frequency, or response format. Only authentication requirement is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but lacks necessary detail, making it under-specified. It could be improved with front-loaded key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and low parameter documentation, the description is severely incomplete. It fails to convey the subscription model, parameter effects, or return values.
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?
Both parameters have no descriptions in the schema, and the tool description does not explain their purpose or behavior (e.g., what messageCount and timeoutMs control). This is a critical gap.
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 specifies the action 'subscribe' and the resource 'DCP changes', which is clear. However, the acronym 'DCP' is not explained, requiring additional context. The inclusion of authentication requirement is helpful.
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 (e.g., other subscription tools). There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states 'subscribe ... push notifications' but does not clarify whether this is a one-time request or ongoing subscription, how to manage the subscription (e.g., cancel), or what triggers notifications. The behavioral model is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It could be improved with bullet points or clearer phrasing, but it does not contain unnecessary words.
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 (subscription tool with two parameters, no output schema, many sibling tools), the description is insufficient. It omits important details such as how to interpret results, how to stop the subscription, and how it interacts with other Earn tools like 'placeEarnOrder'. The description is not complete enough for an agent to use effectively.
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 description does not explain the parameters 'messageCount' and 'timeoutMs' at all. Since schema coverage is 0%, the description must fill this gap but fails to do so. The purpose of these parameters is entirely ambiguous.
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 ('subscribe') and the target ('Earn dual-currency financial product push notifications'). The name and description together convey the purpose, though it could be more specific about what 'push notifications' entails. It distinguishes itself from other subscription tools by specifying 'EarnDualAssets' but does not differentiate from similar subscribe tools for other product types.
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. Given the large number of sibling subscribe tools (e.g., subscribeAdlAlert, subscribeDcp) and earn-related tools, the description should indicate appropriate contexts or prerequisites, but it does not.
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 only mentions subscription to real-time updates but fails to disclose behavioral traits such as connection management, side effects, or how updates are delivered. The description is insufficient for understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but overly brief. It front-loads the purpose but omits necessary details, making it borderline under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, no annotations, and is a subscription (implying ongoing interaction), the description is far from complete. It does not explain how to manage the subscription, what the updates contain, or any prerequisites.
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 parameters are undocumented in schema. The description adds no information about the three parameters (category, messageCount, timeoutMs), leaving their semantics completely unexplained.
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 ('Subscribe'), the resource ('real-time execution updates'), and context ('for your account'). It uses a specific verb and resource, but does not explicitly differentiate from sibling tools like 'subscribeExecutionFast'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states what it does without context on appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only notes that authentication is required. No details are given about subscription lifecycle, data delivery method (e.g., WebSocket), push frequency, rate limits, or how to stop the subscription. Given the lack of annotations, the description carries the burden of behavioral disclosure but falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which makes it concise, but it sacrifices important information. It is front-loaded with the core action, but the lack of detail reduces its effectiveness.
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 subscription tool with multiple similar siblings, the description is incomplete. It does not explain the subscription mechanism, output format, or how it differs from other subscription tools. The agent would likely struggle to use it correctly without additional context.
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 two parameters (messageCount, timeoutMs) with 0% schema description coverage, and the description does not mention or explain them. The agent receives no guidance on what these parameters control or how to set them appropriately.
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: subscribing to fast execution push notifications. It also mentions authentication requirement. However, it does not differentiate from similar sibling tools like subscribeExecution, which may have overlapping functionality.
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 only prerequisite mentioned is authentication, but there is no context on typical use cases 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?
The description only says 'subscribe', which implies a subscription that sends updates, but it lacks details on duration, unsubscription behavior, rate limits, or whether it's a one-time snapshot. Annotations are absent, so the description carries full burden but fails to disclose critical behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise, but it sacrifices necessary detail. Being concise is positive, but the brevity leads to under-specification, missing key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description is too brief to be complete. It does not explain subscription behavior, parameter roles, or usage context, making it inadequate for an AI agent to use correctly.
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 coverage is 0%, and the description adds no information about any of the 5 parameters. The agent must rely solely on the schema, which may not clarify the meaning of 'messageCount', 'timeoutMs', or how 'depth' values correspond to levels. Description offers zero parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it subscribes to order book depth snapshots, specifying the mode. It distinguishes from siblings by mentioning 'subscribe-snapshot mode', but could be clearer on how it differs from other orderbook subscriptions like 'subscribeRpiOrderbook'.
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 (e.g., getOrderbook, subscribeSpreadOrderbook). There is no mention of when-not-to-use or context for selecting this subscription type.
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 provided, so the description carries full burden. It only mentions authentication requirement. It does not disclose whether the subscription is one-time or continuous, how to manage the subscription, or what events are received. For a subscription 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (11 characters in Chinese), efficient, and front-loaded with key info. However, it sacrifices informativeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a subscription tool with no output schema, no annotations, and many sibling tools), the description is incomplete. It lacks details on the event stream, subscription lifecycle, and differentiation from similar 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?
Input schema has 2 parameters with 0% description coverage (schema has no descriptions). The description does not explain the meaning of messageCount or timeoutMs beyond their names and types. It fails to add value for parameter usage.
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 'Subscribe to RFQ trades (requires authentication)', which identifies the verb and resource but lacks specificity. It does not clarify whether these are public or private trades, nor does it distinguish from the similar sibling tool 'subscribeRfqPublicTrades'. The purpose is clear but vague.
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 vs alternatives. The only behavioral note is 'requires authentication', which is useful but insufficient for distinguishing from other subscribe tools like subscribeRfqPublicTrades, subscribeRfqQuotes, etc.
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 fails to disclose behavioral traits. It does not explain the subscription nature (e.g., continuous stream vs. single snapshot), how to stop the subscription, or the data format. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it concise, but it lacks structure and essential details. While brevity is valued, it sacrifices 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 tool's complexity (4 parameters, no output schema, no annotations, and many sibling subscription tools), the description is critically incomplete. It fails to explain what 'RPI' is, the nature of the subscription, how multiple messages are handled, and how this relates to other order book tools.
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 4 parameters with 0% description coverage, and the tool description adds no meaning to any of them (symbol, category, messageCount, timeoutMs). Users must infer the purpose of each parameter from names alone, which is insufficient.
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 subscribes to an 'RPI order book snapshot' with a specific verb ('subscribe') and resource. However, it does not explain what 'RPI' stands for or how it differs from the sibling 'subscribeOrderbook' tool, which may cause confusion.
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 'subscribeOrderbook' or 'getRpiOrderbook'. There is no context for selection criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the basic action. No annotations are present, so the description carries the full burden. It fails to mention side effects, authentication requirements, rate limits, or any other behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, which is positive, but it sacrifices necessary detail. It is front-loaded but does not earn its place fully due to missing 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 tool has five parameters, no output schema, and eleven sibling tools including 'getMyAds', 'postAd', and 'updateAd', the description is far too sparse. It does not provide enough context to understand the tool's role in the P2P marketplace domain.
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?
With 0% schema description coverage, the description adds no meaning to the parameters tokenId, currencyId, side, page, or size. None of these are explained, leaving the agent to infer from naming alone, which is insufficient for reliable invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get online P2P advertisements,' which clearly identifies the action and resource. However, it does not differentiate from the sibling tool 'getMyAds', which likely returns the user's own ads, creating ambiguity about whether this tool returns all public ads 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. There is no mention of context, prerequisites, or scenarios where another tool like 'getMyAds' would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a rate limit of 5 requests per UID, which is a behavioral trait. However, with no annotations, it lacks details on authentication, error states, or what happens if no contracts are found. The rate limit is useful but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line plus rate limit note), but it is under-specified rather than efficiently concise. It lacks structure and could include more detail without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and many sibling tools, the description is incomplete. It does not explain the return format, filtering options, or how it differs from similar tools like getCryptoLoanFixedSupplyOrderInfo.
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%, yet the description provides no information about the 6 parameters (orderId, supplyId, supplyCurrency, term, limit, cursor). It fails to add any meaning beyond the raw 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 it queries active supply contracts (lending positions), using a specific verb and resource. It distinguishes itself from related siblings like getCryptoLoanFixedSupplyOrderInfo and getCryptoLoanFixedSupplyOrderQuote, which are for order info and quotes, though not explicitly.
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 getCryptoLoanFixedSupplyOrderInfo or getCryptoLoanFixedBorrowContractInfo. The sibling list includes many similar tools, but the description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'Query yield history' without disclosing pagination (cursor/limit), required category, or any other behavioral traits. Very minimal information.
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?
Single sentence, concise. Could be improved by including more information without being overly verbose. Currently satisfactory but not excellent.
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 6 parameters, no output schema, and no annotations, the description is incomplete. Does not mention time range, pagination, or productId significance. Lacks 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?
Schema has 6 parameters with 0% description coverage. Description adds only that category supports 'FlexibleSaving' and 'OnChain', but does not explain productId, startTime, endTime, limit, cursor. Minimal value added over 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?
Clearly states 'Query yield history' as verb+resource. Mention of 'FlexibleSaving' and 'OnChain' indicates supported categories, but does not differentiate from sibling tools like getEarnAprHistory or getEarnHourlyYieldHistory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description implies the two categories but does not explain when to choose this over other yield history tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It does not explain whether subscription is persistent, if it can be cancelled, authentication needs, or what triggers the push. The description only states the action without any behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it may be too brief for a subscription tool. It is front-loaded but lacks sufficient detail, earning a middle score.
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 subscription tool with three parameters and no output schema, the description is incomplete. It does not explain what ADL alerts are, subscription lifecycle, or how to interact with the subscription (e.g., unsubscribing). It provides minimal context for 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%, and the description adds no meaning beyond parameter names. The parameters (coin, messageCount, timeoutMs) are self-explanatory, but the description does not clarify their roles or constraints.
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 '订阅 ADL 预警推送' clearly indicates the tool subscribes to ADL (Auto-Deleveraging) alert push notifications. It distinguishes from other subscribe tools for different data streams, and from getAdlAlert which likely queries alerts. However, it could be more explicit about the nature of ADL alerts.
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 subscribeKline or getAdlAlert. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions 'subscribe' without detailing behavioral traits such as streaming behavior, data format, connection requirements, or side effects. This leaves the agent with insufficient information.
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 short and to the point, but it sacrifices necessary detail. It is not verbose, but it is under-specified for a subscription tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and the presence of many sibling subscription tools, the description fails to provide enough context about what data is returned, how the subscription works, or how to handle the stream. It is incomplete.
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 schema has 0% description coverage, and the description does not explain the parameters 'messageCount' and 'timeoutMs'. The agent must rely on parameter names, which may not convey semantics clearly (e.g., default values and minimums are in schema but not explained).
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 '订阅 RFQ 公开成交' clearly states the tool subscribes to RFQ public trades. However, it does not differentiate from sibling tools like 'subscribeRfqTrades' or 'subscribePublicTrade', leaving ambiguity about the 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 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 'subscribeRfqTrades' or 'subscribePublicTrade'. There is no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses authentication but no other behavioral details such as whether it opens a WebSocket, how subscription works, or effects of parameters. Very limited.
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?
Single sentence with no wasted words. It is concise, though it could include more information 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 two parameters and no output schema, the description is inadequate. It does not explain the behavior of the subscription or how parameters affect it, leaving significant gaps.
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 coverage is 0% and the description does not mention any parameters. Since coverage is low, the description must compensate, but it fails entirely to explain messageCount or timeoutMs.
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 (subscribe) and resource (RFQ quotes) and notes authentication. It is specific but does not differentiate from sibling subscription tools like subscribeRfqPublicTrades, which reduces clarity slightly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only mentions authentication, but fails to provide context for usage decisions.
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 provided, so description carries full burden. It only notes authentication requirement but omits side effects (e.g., how subscriptions are managed, how to unsubscribe, whether it's a one-time or persistent subscription).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise. However, it may be too brief, missing important context. It is front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (subscription with parameters), lack of output schema, and sibling diversity, the description is incomplete. It does not explain subscription semantics, how parameters affect behavior, or how to manage the subscription.
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% and the description does not mention the two parameters (messageCount, timeoutMs). The description adds no meaning beyond the schema, failing to compensate for the lack of 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 '订阅 RFQ 请求（需要鉴权）' clearly indicates the tool subscribes to RFQ requests using the verb 'subscribe' and resource 'RFQ requests'. It distinguishes from sibling subscription tools like 'subscribeOrderbook' or 'subscribeTickers' by specifying the resource.
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. There is no context about prerequisites, exclusions, or scenarios where another subscription tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose behavioral traits such as subscription duration, triggering conditions, or what 'push' entails. The parameters hint at polling/waiting behavior, but this is not explained.
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 but lacks essential details. It earns its place without waste, but the brevity undermines clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, output schema, or parameter descriptions, the description is severely incomplete. It provides only a label, leaving the agent unable to understand tool behavior or parameters.
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%, yet the description does not explain what messageCount or timeoutMs do. The agent has no semantic understanding of the parameters from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '订阅系统状态推送' clearly states the action (subscribe) and resource (system status push), and distinguishes it from sibling subscription tools like subscribeAdlAlert or subscribeOrderbook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other subscribe tools. The description does not mention prerequisites, context, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose that the tool establishes a subscription for real-time ticker data, nor does it explain return behavior or potential side effects (e.g., connection handling).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one phrase), which is concise but lacks necessary structure and detail. It could be expanded slightly to include parameter info or usage context without becoming 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 4 parameters with 0% schema description coverage, no annotations, and no output schema, the description is severely incomplete. It does not explain the subscription behavior, return data, or how to use the parameters.
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 coverage is 0%. The description fails to explain any parameter: symbol, category, messageCount, or timeoutMs. The agent has no insight into parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '订阅行情快照（Ticker）' clearly states the action (subscribe) and resource (market ticker snapshots), distinguishing it from sibling tools like subscribeKline or subscribeOrderbook.
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 (e.g., subscribeKline for kline data). No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It indicates a read operation ('Query') and a range constraint. However, it fails to mention pagination (cursor/limit), response format, or any rate limits. This is insufficient for a tool with 6 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, using two short sentences and a bullet point. It front-loads the core purpose. However, brevity comes at the cost of missing essential parameter details, which could be added without significantly increasing length.
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 6 parameters, 0% schema coverage, no output schema, and no annotations, the description is woefully incomplete. It lacks parameter semantics, pagination details, and output format. An AI agent would struggle to use this tool correctly without external knowledge.
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%, placing full burden on the description. The description does not explain any of the 6 parameters (category, productId, startTime, endTime, limit, cursor). It only implies date range limits but provides no format or units. Without this, an AI agent cannot correctly use the 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 'Query' and resource 'hourly yield details'. It also specifies the product type 'FlexibleSaving', which helps distinguish from sibling tools that may query other yield products or time granularities. However, 'details' is vague and could be more specific about what data is returned.
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 explicitly limits usage to 'FlexibleSaving' and mentions a 'Maximum query range is 7 days', which provides clear usage constraints. However, it does not explicitly state when not to use this tool or provide alternatives among the many sibling yield-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that amount fields are computed dynamically based on real-time prices and specifies a rate limit of 10 req/s. Since no annotations are provided, the description carries the full burden. However, it does not explicitly state that the tool is read-only, nor does it describe error behavior or response characteristics. The information is useful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences and a rate limit note. It is front-loaded with the primary purpose. However, it omits essential parameter information and could be more structured. Every sentence earns its place, but the overall brevity leaves gaps.
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, no output schema, and 0% parameter documentation, the description is insufficient. It does not explain what constitutes a 'position,' how parameters filter results, or what the output contains. An agent would need significant external knowledge to use this tool correctly.
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 neither parameter (productId, baseCoin) is described in the schema. The description does not explain these parameters or how they affect the query. It adds no value beyond the schema structure, failing to compensate 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 tool's purpose: 'Query active Liquidity Mining positions for the current user.' It includes a specific verb (query) and resource (positions). However, it does not distinguish this tool from similar siblings like getLiquidityMiningOrders or getLiquidityMiningProducts, which reduces clarity in a crowded toolset.
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 only mentions a rate limit, but does not explain use cases, prerequisites, or when not to use it. Sibling tools are numerous but no differentiation is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral info. It discloses rate limits and lack of auth, but does not explain return format, pagination, or side effects, leaving gaps for the agent.
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 short and front-loaded with the purpose, but omits critical parameter details. It is concise but 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 no output schema and low schema coverage, the description is incomplete. It provides basic context (no auth, rate limit) but lacks parameter explanations and return value details, which are essential for correct 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?
Schema description coverage is 0% for both parameters (baseCoin, quoteCoin). The description does not explain what these parameters do, leaving the agent without guidance on how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Query available Liquidity Mining product listings' clearly states the action (query) and resource (liquidity mining product listings). However, it does not differentiate from sibling tools like getLiquidityMiningOrders or getLiquidityMiningPositions, which could cause confusion.
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 mentions 'No authentication required (guest access supported)' indicating public availability, but provides no guidance on when to use this tool versus alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that under portfolio margin mode, the tool returns an error, which is useful. However, no annotations are provided, and the description does not mention other critical behaviors like rate limits, idempotency, or whether it is a read-only operation (implied by 'Query' but not explicit).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (three sentences) and to the point. The first sentence conveys the core purpose, and the note adds important behavior. However, the structure could be improved by grouping the note more clearly or adding a usage hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should at least outline the return format or fields. It does not. Combined with lacking parameter descriptions, the tool definition feels incomplete, especially for a query tool. The note about portfolio margin adds some context but is insufficient.
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 the schema itself provides no parameter descriptions. The tool's description does not explain the meaning or expected format of the 'symbol' and 'category' parameters beyond the enum for category. It only describes the output, not the inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries 'futures leverage info' and lists examples (symbol leverage, side, position mode). It also specifies supported contract types. However, it does not explicitly distinguish this from sibling tools like getPositionInfo or getAccountInfo, which may overlap.
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. The note about portfolio margin returning an error is a behavioral constraint, not usage context. No when-to-use or when-not-to-use pointers are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only adds a rate limit (10 req/s UID) but fails to mention that the tool is read-only, whether authentication is required, or details about pagination and response format. For a query tool with no output schema, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose, followed by a separate rate limit note. It is concise, but could potentially include more parameter details without becoming overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and required enum, the description lacks crucial context such as pagination behavior (implied by cursor/limit), date range semantics, and expected return format. The rate limit is useful but insufficient for 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?
Schema description coverage is 0%, and the description does not explain any parameter meanings beyond what the schema already provides. Parameters like startTime, endTime, and cursor are left without semantic context, despite being key for proper usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries 'user's daily yield distribution records,' using a specific verb and resource. However, it does not explicitly differentiate from sibling tools like getDistributionRecord or getTokenHourlyYield, which may have similar purposes.
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 getDistributionRecord or getTokenHourlyYield. The rate limit is mentioned but does not indicate appropriate usage contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses delays during peak lending, non-cancellable redemptions, and longer OnChain processing. However, it misses auth requirements, rate limits, and other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, with two sentences and bulleted notes. The purpose is front-loaded. Each sentence adds value, though parameter details are missing.
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 10 parameters, 7 required, a nested object, and no output schema, the description lacks essential context. It does not explain parameter usage, return values, or prerequisites, making it inadequate for a complex tool.
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%, and the description provides no meaning for any of the 10 parameters. The tool name and summary do not explain what parameters like 'productId', 'redeemPositionId', or 'interestCard' are for.
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 'Place a Stake or Redeem order', specifying the verb and resource. It distinguishes the tool's action from siblings like executeLPStake or placeFixedTermOrder, though it doesn't explicitly differentiate from similar earn order tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The notes mention delays and cancellation restrictions, which are behavioral, but do not help an agent choose between this and sibling tools like placeAdvanceEarnOrder or executeLPStake.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It states it repays entire loan principal and interest and includes a rate limit. However, it omits critical details: no mention of authentication requirements, whether the loan is closed after, or any side effects beyond repayment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus rate limit), which is concise but under-specified. It wastes no words but fails to provide necessary parameter details or usage context, making it only minimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It does not describe return values, error conditions, or confirm that the operation is successful. The two-parameter schema is not fully explained, leaving the agent with gaps.
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 for parameters. The description adds no meaning to 'loanId' or 'loanCurrency', failing to explain their purpose, format, or how to obtain valid values. This leaves an AI agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Repay entire loan principal and interest', which clearly identifies the action and resource. The tool name 'postCryptoLoanFixedFullyRepay' aligns perfectly, and it is distinct from sibling tools like 'postCryptoLoanFixedRepayCollateral' or 'quickRepayment'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not specify prerequisites (e.g., loan must exist, need to have loanId), nor does it mention scenarios where partial repayment or other repayment methods would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions a rate limit but omits details like required permissions, fund locking, or destructive effects. For a financial mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: one for purpose, one for rate limit. It's front-loaded and efficiently worded, though the rate limit could be moved to 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?
With 5 parameters, no parameter descriptions, no output schema, and no annotations, the description is severely incomplete. It fails to explain how to use parameters, return values, or prerequisites.
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 coverage is 0% (no parameter descriptions in the schema), and the description adds no meaning to any of the 5 parameters. The agent gets no help understanding orderCurrency, orderAmount, etc.
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 'Lend crypto to earn fixed interest.' This is a specific verb+resource, and it distinguishes from sibling tools like postCryptoLoanFixedBorrow (borrowing) by explicitly mentioning lending.
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 vs. alternatives (e.g., postCryptoLoanFlexibleBorrow or other loan tools). The description only states the action without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses authentication method, ACL permission, and rate limit, which are useful behavioral traits beyond what annotations might provide. However, it does not describe the nature of the results (e.g., format, pagination, filtering) or confirm read-only behavior, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose, followed by auth and rate limit details. It is compact but could be slightly more efficient by omitting redundant info like 'OpenAPI interface'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should provide more context about the tool's return value, usage context, and differentiation from siblings. It covers only auth and limits, leaving the agent underinformed.
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 two required parameters with no descriptions, and the description does not explain their meaning or valid values. Since schema coverage is 0%, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Query cryptocurrency exchange results using a quote transaction ID,' which clearly identifies the tool's action and resource. It distinguishes from many sibling tools that are also query-like, but does not precisely define what 'exchange results' means, leaving some 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 lists authentication and rate limits but does not mention when this tool is appropriate or what distinguishes it from similar tools like getQuotes or queryTrade.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds some transparency by noting API key auth, ACL permissions, rate limits, and KYC. However, it does not disclose side effects, whether it's a write operation, or the response format beyond mentioning conversion rate and quote ID.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes bullet points for requirements. It is mostly concise, though the purpose could be more prominently 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 tool has 10 parameters, no output schema, and no annotations, the description is incomplete. It covers authentication and constraints but fails to explain parameter usage and return values, leaving significant gaps for an agent.
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 coverage is 0%, and the description provides no explanation of any of the 10 parameters (5 required). The tool name and brief purpose do not compensate for the lack of 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 applies for a conversion quote and returns rate and ID. However, it does not differentiate from sibling 'applyQuote', which appears to be a similar action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists authentication, permissions, rate limits, and KYC requirements, but provides no guidance on when to use this tool versus alternatives like 'applyQuote' or 'createQuote'.
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. It only states the basic operation (batch enable/disable) but does not mention side effects, authorization requirements, rate limits, or error handling. Critical behavioral traits are missing 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks sufficient detail. It is front-loaded with the key action, but the brevity sacrifices informative content. It is not verbose, but it is under-specified.
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 modifies state (collateral switches), has no output schema, and has a sibling for single updates, the description should include prerequisites, mutation implications, or error scenarios. It only states the basic operation, leaving completeness gaps.
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 the description adds no explanation of the 'request' parameter. The description merely repeats the function name without clarifying the parameter structure (array of objects with coin and collateralSwitch). The agent gains no additional insight beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Batch enable or disable multiple coins as collateral' uses a specific verb (batch enable/disable) and clearly identifies the resource (coins as collateral). It distinguishes this tool from the sibling 'setCollateralSwitch' which handles single coins, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. Although the name implies batch operations, there is no guidance on context or exclusion, such as 'use this for multiple coins; for single coin, use setCollateralSwitch'. This leaves the agent without clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states the basic operation. It does not disclose prerequisites (e.g., coin must be registered), side effects, or whether changes are reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, but it is so minimal that it fails to provide necessary context. It is concise but not optimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and parameter descriptions, the description is insufficient for an agent to understand the tool's complete behavior, such as return value or constraints.
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 coverage is 0% and the description adds no meaning beyond parameter names. 'coin' and 'collateralSwitch' are left to inference with no hints on valid values or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Enable or disable' and the resource 'collateral for a specified coin', which distinguishes it from sibling tools like setBatchCollateralSwitch.
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 setBatchCollateralSwitch. The description does not mention use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses authentication need but fails to explain subscription behavior: whether it's continuous, how to stop, what triggers pushes, or timeout implications. Key behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (single phrase) but lacks structure and necessary details. Front-loading purpose is good, but 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?
Given the tool's complexity (subscription with two parameters, no output schema, many similar siblings), the description is incomplete. It does not explain how the subscription works, how to stop it, or differentiate from other subscription tools.
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%, and the description does not mention the parameters (messageCount, timeoutMs) at all. It adds no meaning beyond the schema, leaving the agent to infer their role in the subscription context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool subscribes to Spread execution push and requires authentication. The verb 'subscribe' and resource 'spread execution push' are specific and distinguish it from sibling tools like subscribeExecution or subscribeSpreadOrder.
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 mentions authentication requirement but provides no guidance on when to use this tool vs other subscription tools (e.g., subscribeExecution, subscribeSpreadOrder). No explicit when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not explain behavioral aspects such as connection management, how to stop receiving updates, or the meaning of the parameters (messageCount, timeoutMs). The term 'real-time' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise. However, it omits necessary context for a subscription tool among many siblings, so its brevity sacrifices 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 it is one of many similar subscribe tools with 2 undocumented parameters and no output schema, the description lacks completeness. It does not describe expected inputs, outputs, or how the subscription lifecycle works.
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 and the tool description does not explain the parameters at all. messageCount and timeoutMs are left to the user's interpretation, adding zero meaning beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'subscribe' and the resource 'wallet updates' for the 'Unified Trading Account (UTA)'. It distinguishes this tool from numerous other subscribe tools focused on different resources (orderbook, tickers, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many other subscribe tools (e.g., subscribeOrderbook, subscribeTickers). There is no mention of prerequisites, alternatives, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the operation (get details) without disclosing any behavioral traits such as authorization requirements, rate limits, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence that gets straight to the point. No unnecessary words, though it could benefit from slightly more detail on the parameter.
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 (1 param, no output schema), the description is minimal but missing critical context about the parameter and what 'details' entails. The agent might need more information to use it correctly.
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%, but the description does not explain the meaning of the single required parameter 'itemId'. The agent has no context on what this ID represents (e.g., ad ID vs transaction ID).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get details of a specific P2P advertisement', using a specific verb and resource. It distinguishes from sibling tools like 'getMyAds' (list) and 'getAds' (likely other list) by focusing on a single ad.
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 vs alternatives like 'getMyAds' or 'getAds'. The description implies usage for a specific ad but does not explicitly state when to choose this over other ad-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action without disclosing whether the removal is irreversible, what side effects occur, or any authorization requirements. With no annotations, the description carries the full burden but fails to provide sufficient behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. However, it could be slightly more informative 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 simplicity of the tool (one parameter, no output schema), the description is incomplete. It omits crucial details like what happens after removal, any prerequisites, or return values.
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 sole parameter 'itemId' is not explained in the description. With 0% schema description coverage, the description adds no meaning beyond the schema, leaving the agent to guess its purpose (e.g., ad ID).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (cancel/remove) and the resource (P2P advertisement), making the tool's purpose immediately obvious. It distinguishes from siblings like postAd or updateAd.
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 updateAd or when not to use it. The description is purely functional without 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?
The description provides rate limit info but lacks details on side effects, prerequisites, or what happens if the mode is already set. No annotations exist to supplement, so more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no filler, includes rate limit info efficiently. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the main action and rate limit. However, it lacks explanation of parameter values, prerequisites, and potential errors, reducing completeness.
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 single required parameter 'spotMarginMode' has enum values '0' and '1' in the schema, but the description does not explain which value corresponds to enable or disable. With 0% schema description coverage, the description fails to add necessary meaning.
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 'Enable or disable' and the resource 'spot cross margin trading mode', which distinguishes it from siblings like setMarginMode. However, it could be more explicit about the context (e.g., that it toggles a specific mode).
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 setMarginMode or spotMarginSetLeverage. There are no when-to-use or when-not-to-use indications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides a rate limit of 100 req/s and notes on decimal precision and idempotency via specCode. This adds behavioral context beyond the bare description. However, it lacks information on side effects (e.g., whether it modifies state), required permissions, or error scenarios. With no annotations, the description only partially fills the transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. It efficiently conveys rate limit and key constraints in a few sentences. However, the notes could be better structured (e.g., bullet points) for readability.
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 required parameters, no output schema, and many sibling tools, the description is too brief. It lacks parameter descriptions, usage context, and details about the distribution process (e.g., what happens after distribution). The tool feels incomplete without more context for the 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?
The description provides no explanation for 4 of the 5 required parameters (accountId, awardId, amount, brokerId). Only specCode is partially described in the notes (up to 8 characters, used for idempotency). Schema coverage is 0%, so the description fails to add meaningful semantics for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool distributes a voucher to a user. It is a specific verb+resource. While there is no direct sibling with a similar name, the briefness and lack of explicit differentiation from other award-related tools slightly reduce clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. The description does not mention prerequisites, typical use cases, or situations to avoid. The agent is left to infer when 'distributeAward' is appropriate among hundreds of siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that only active/settling positions are returned and explains the coin parameter's filtering behavior. Rate limit is provided. However, it does not explain cursor-based pagination, the meaning of productId, or any potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose. However, the 'DiscountBuy notes' header adds slight confusion and could be removed or integrated more naturally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is incomplete. It does not explain what the tool returns, how pagination works, or the meaning of all parameters. Essential behavioral details are missing.
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?
With 0% schema description coverage, the description should add meaning to parameters. Only the coin parameter is explained with an example. Other parameters like category, productId, limit, and cursor are not described, leaving significant gaps.
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 'Query your active positions' with a specific verb and resource. The tool name 'getAdvanceEarnPosition' distinguishes it from sibling tools like 'getEarnPosition'. However, the mention of 'DiscountBuy notes' is somewhat confusing and could imply category-specific behavior that is not fully explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as getEarnPosition. It mentions required permissions and rate limits but lacks context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like read-only nature, authentication requirements, rate limits, or return format. The description adds minimal value beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no extraneous information. Functionally concise with clear action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the complexity of pagination implied by currentPage and size parameters, the description leaves significant gaps. It does not explain what the response contains or how pagination works.
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%, and the description adds no explanation for the three parameters (orderId, currentPage, size). Parameter names are somewhat self-explanatory, but the description fails to clarify their usage or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves chat messages specifically for P2P orders, using specific verb 'Get' and resource 'chat messages'. The scope 'for a P2P order' distinguishes it from other message-related tools like 'readMessages'.
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 such as 'readMessages'. No context about prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description includes a rate limit (5 requests per UID), which is a useful behavioral constraint. However, it does not disclose read-only nature, idempotency, or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences with no redundant information. The first sentence states purpose, the second provides a key constraint (rate limit).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 6 undocumented parameters, the description is inadequate for complete understanding. It does not explain what 'details and history' includes or how parameters affect the query.
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% with 6 parameters. The description adds no explanation of what each parameter does, leaving the agent to infer from parameter names alone.
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 'Query' and the resource 'borrow order details and history'. While it doesn't explicitly mention 'fixed borrow', the tool name provides that context. It distinguishes from siblings like getBorrowHistory but not from queryFixedBorrowOrders.
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 vs alternatives like queryFixedBorrowOrders or getBorrowHistory. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes a rate limit annotation ('5 requests per UID'), which adds behavioral context beyond the schema. However, it does not disclose read-only nature or pagination behavior implied by limit and cursor 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 two sentences, including the rate limit note, with no unnecessary words. It is appropriately sized for a simple query tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 0% parameter coverage, the description is incomplete. It does not explain return values or how to use parameters effectively, leaving significant gaps for a 4-parameter tool.
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%, and the description does not explain any of the four parameters (orderId, orderCurrency, limit, cursor). It fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query loan renewal history and information', specifying the resource (loan renewal) and action (query). It distinguishes from sibling tools like getCryptoLoanFixedBorrowContractInfo by focusing on renewal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other crypto loan query tools or alternatives. The description does not mention context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it queries position information, implying a read operation, but does not disclose whether it has side effects, permissions needed, or other behavioral traits. The yield accumulation note adds some context but not enough for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The yield accumulation detail is somewhat tangential but not overly verbose. Could be more focused on the tool's primary 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?
No output schema and no description of return values. For a query tool, the agent needs to know what information is returned. The description is insufficient for the agent to understand the tool's full usage context.
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%, yet the description provides no explanation of any parameter. The category, productId, and coin parameters are left undefined, forcing the agent to infer from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries 'current staked position information', which is specific. However, it does not differentiate from sibling tools like getAdvanceEarnPosition or getFixedTermPosition, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The yield accumulation detail does not provide usage context, so the agent receives no help in selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that no authentication is needed, which is transparent. However, it does not mention other behavioral traits such as rate limits, data freshness, or idempotency. Given the lack of annotations, more disclosure would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first states the core function, and the second adds the important auth requirement. No unnecessary 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?
The description covers the tool's purpose and auth, but lacks details about return structure, pagination, or filtering behavior. With no output schema, additional context about the response would improve completeness.
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 description does not explain the meaning or expected values of the input parameters ('category' and 'coin'). With 0% schema coverage, the description should compensate, but it instead focuses on output fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool queries earn product information, listing specific output fields (APR, stake amounts, status). This distinguishes it from related sibling tools like getAdvanceEarnProduct or getFixedTermProduct, though it does not explicitly differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guideline provided is 'No authentication required.' There is no advice on when to use this tool versus alternatives, nor any prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only reveals that authentication is not required. It does not disclose other behavioral traits such as rate limits, data freshness, or side effects (e.g., read-only nature). The description is too sparse for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences. It is front-loaded and wastes no words. However, it could include more context without sacrificing 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 no output schema and no annotations, the description is incomplete. It does not explain what the listing contains, whether there are filters, or how to interpret results. Compared to sibling tools, it lacks necessary detail for an AI agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema coverage is 100%. The description adds no additional meaning beyond the tool name, but since there are no parameters to document, a baseline score of 3 is appropriate. It could have described the output structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Query') and resource ('Hold-to-Earn product listings'). However, it does not differentiate from similar sibling tools like getEarnProduct or getAdvanceEarnProduct, which query other product types.
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 includes 'No authentication required,' which provides some usage context but does not specify when to use this tool over alternatives. There is no guidance on prerequisites 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions cursor-based pagination and a rate limit, but does not disclose whether it requires authentication, what side effects exist, or any other behavioral traits beyond the basic read operation implied by 'Query'.
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 very concise, two sentences, no fluff. However, for a tool with 6 parameters, more structure (e.g., listing key parameters) could be preferred.
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 6 parameters, 0% schema coverage, no output schema, and no annotations, the description is insufficiently complete. It does not explain what the records contain, how to paginate, or the meaning of baseCoin/quoteCoin.
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%, and the description does not explain any of the 6 parameters. The only hint is 'cursor-based pagination' which indirectly relates to cursor and limit, but not explicitly. The description adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries yield claim records for Liquidity Mining positions, and mentions cursor-based pagination. It distinguishes from sibling tools like getLiquidityMiningLiquidationRecords or getLiquidityMiningOrders.
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 other liquidity mining query tools. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses rate limit (50 req/s IP) and no auth required, which are useful behavioral details. Since annotations are absent, the description provides some transparency but could mention data range or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences and a rate limit/auth note. No unnecessary words, front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters with enums and no output schema, the description is incomplete. It fails to explain the parameter meanings or the response format, leaving the agent to guess.
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 coverage is 0% and the description does not explain the parameters (coin and range). The enum values (e.g., '1', '2', '3' for range) are cryptic; the agent cannot determine what they represent without 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 clearly states the tool queries historical APR data for a product. However, it does not distinguish this tool from siblings like getEarnAprHistory or getTokenHourlyYield, which could confuse an agent on which to use.
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 vs alternatives. The description only says what it does and includes rate limit/auth, but no context on appropriate use cases 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 exist, so the description should fully disclose behavior. It only states it's a query and includes a rate limit. It does not mention pagination (cursor, limit), what constitutes 'order history' (completed vs pending), or behavior when multiple filters are applied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus rate limit) and front-loaded with the main purpose. While it could include more detail, it avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters and no output schema. The description omits context on return format, pagination, filtering by time/orderType, and cursor usage. It is not sufficiently complete for an agent to use confidently.
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 coverage is 0%, so the description must compensate. It explains orderLinkId and orderId but ignores other parameters (coin, orderType, startTime, endTime, cursor, limit). The rate limit note adds some value but does not address parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries 'BYUSDT Token order history', using a specific verb and resource. It distinguishes from sibling tools like getOrderHistory (general) and getLPOrderList (liquidity pools) by specifying the token type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as getOrderHistory, getOrderList, or getLPOrderList. The description does not mention exclusions or preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description reveals the default time range (last 30 days) which adds some behavioral context. However, it does not disclose other traits like idempotency, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no redundancy. Every part adds value: the purpose statement and the time range rule.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description is insufficient. It omits pagination behavior, parameter meanings, and response structure, leaving the agent to guess.
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 coverage is 0% and description only hints at time parameters (startTime, endTime) implicitly. The other 5 parameters (transferId, coin, status, limit, cursor) are completely undocumented in the description, leaving the agent without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it queries internal transfer records between account types under same UID. It is specific but does not explicitly differentiate from sibling tools like universalTransferListQuery or transferCoinListQuery, which could overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Only provides a default time range rule, but no context on prerequisites, exclusions, or recommended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fails to disclose mutation behavior, required permissions, side effects, or response format. The note about 'Balance' method is useful but minimal. With no annotations, the description should carry more behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) with no wasted words, but it is too sparse to be fully informative. It could add parameter details 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 no output schema and no annotations, the description is incomplete. It does not explain what happens upon success, error conditions, or any additional context needed for correct 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?
Schema description coverage is 0%, meaning the description must explain parameters. The description does not mention any parameter meanings or expected values, leaving the agent to guess what orderId, paymentType, and paymentId represent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (mark as paid) and the resource (P2P order), and includes a notable constraint. It distinguishes from sibling tools like createOrder, cancelOrder, etc.
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 P2P orders but does not explicitly state when to use it versus alternatives or provide any prerequisites. No exclusion criteria beyond the 'Balance' method note.
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?
Without annotations, the description carries full burden but only mentions a rate limit. No disclosure of idempotency, side effects, or behavior for already-filled orders. Implicitly a mutation but lacks detail.
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?
Efficient two-sentence structure. First sentence clearly states purpose. Rate limit is a useful addition, though more detail could be added without verbosity.
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 many sibling tools, the description is incomplete. It lacks return value info, error handling, and behavior context beyond cancellation.
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 coverage is 0%, and the description does not explain the 'orderId' parameter beyond its name. No format, source, or constraints are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Cancel' and resource 'a pending borrow order', clearly distinguishing it from sibling tools like postCryptoLoanFixedBorrow (create) and generic cancel tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 (e.g., cancelOrder, batchCancelOrders). No prerequisites, exclusions, or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral context is a rate limit of 1 request per UID. No annotations exist. The description does not disclose side effects (e.g., refund behavior, impact on orders) or explain what happens upon cancellation.
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: two well-structured sentences. Purpose is front-loaded, rate limit is a helpful addition. No extraneous text.
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?
Lacks crucial context: no output schema, no explanation of refundedAccount, no description of error states or prerequisites. For a cancellation tool, more context is needed for correct 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?
Schema coverage is 0% and the description adds no explanation for parameters. orderId is obvious, but refundedAccount with enum '0','1' is cryptic and not explained, leaving ambiguity about its meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it cancels a pending supply (lending) order. The verb 'Cancel' and resource 'supply order' are specific and distinguish from sibling tools like postCryptoLoanFixedBorrowOrderCancel.
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 such as cancelOrder, cancelAllOrders, or other crypto loan cancel tools. No mention of prerequisites or conditions.
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 exist, so the description bears full responsibility. It mentions auto-conversion and a rate limit, but omits critical details like what happens to collateral after conversion, any fees, prerequisites, or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and bullet points for features. No redundant information, though it could benefit from a bit more structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and sparse parameter info, the description should cover more behavioral aspects. It lacks explanations for return values, minimum amounts, or implications of the action.
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?
With 0% schema coverage, the description must explain parameters. It does not define what `amount` refers to (loan repayment amount or collateral amount) and lacks details for `loanCurrency` and `collateralCoin`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it repays a loan by converting collateral to loan currency, with features like auto-conversion at market rate. This distinguishes it from other loan repayment tools like `postCryptoLoanFlexibleRepay` which likely uses direct loan currency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions 'Convenient when lacking loan currency' which provides a clear use case, but does not explicitly state when to avoid this tool or compare it to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions a rate limit and authentication requirement but does not disclose whether the operation is read-only, any side effects, or what the response contains. The agent is left uncertain about the tool's 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 concise with three sentences covering purpose, rate limit, and rule. It is well-structured and front-loaded with the core purpose. However, it could be more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description should provide more context about the returned information. It does not specify what 'account information' includes, leaving the agent to guess. The lack of disambiguation from sibling tools further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so baseline is 3. The description adds no parameter information, which is acceptable since there are none. No value added but no deficiency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool queries account information using a broker master account. It is clear and specific in terms of verb and resource. However, 'account information' is vague, and there is no differentiation from sibling tools like getAccountInfo or queryBrokerAllUidDetails, which could lead to confusion.
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 a precondition (requires exchange broker master account authentication) but does not offer guidance on when to use this tool versus alternatives. No exclusions or context for selecting this tool among many similar query tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only describes output content, not side effects, authentication requirements, or whether the 'side' parameter filters results. The behavioral impact of the tool is unclear.
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 brief and uses bullet points for readability. It front-loads the main purpose and lists expected returns efficiently, though the parameter omission is a structural gap.
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?
Despite being a simple tool, the description covers return fields and use cases adequately, but the lack of parameter explanation and output schema reduces completeness. Some important context is missing.
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 schema has one parameter 'side' with no description, and the tool description does not mention it at all. This leaves the agent without understanding its purpose or effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the list of fiat and cryptocurrencies, listing specific return fields. However, it does not differentiate from the sibling tool 'CoinListQuery', which may cause confusion.
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?
Three use cases are provided, implying when to use the tool, but there is no explicit guidance on when not to use it or how it compares to alternatives like CoinListQuery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses authentication (API Key), ACL permissions, rate limit, and the old API path. However, it omits details about pagination behavior, default parameter values, and response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with five bullet points, front-loading the purpose. It could be more structured by separating parameter details, but the current format is efficient and scannable.
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 10 optional parameters, no output schema, and no annotations, the description is insufficient. It lacks explanation of pagination, parameter roles, and return values, leaving significant gaps for successful usage.
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 explain parameters. It mentions 'paginated query' and support for asset/OBU accounts but does not map these to specific parameters (cursor, limit, accountType). Most parameters remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool performs a 'paginated query of conversion order list via OpenAPI', identifying the specific resource and action. However, it does not differentiate itself from the sibling 'QueryOrderByPage', which appears to serve a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lists authentication and rate limit details but does not contextualize usage in relation to similar query tools such as getOrderList or QueryOrderByPage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses API key permission and rate limit, which are helpful. However, it does not clarify read-only nature, idempotency, or error behavior. The pagination mechanism (cursor, size) is implied but not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus bullet points, no redundancy. It front-loads the main purpose and then adds permission/rate limit. However, it could be slightly more structured with parameter mappings.
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 6 parameters, no output schema, and no annotations, the description lacks details on pagination behavior, return format, and parameter dependencies. For a query tool, this is insufficient for an agent to fully understand its usage.
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 'order number' and 'time range' filters but does not explicitly map to parameters (e.g., quoteId, startTime, endTime). The meaning of cursor, size, and accountType is left to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a paginated query for small asset conversion history records with filtering options, which is specific and distinct from sibling tools like SmallAssetConvert or QuerySmallAssetList. The verb 'query' and resource 'history records' are clear, though sibling differentiation is not 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?
The description mentions filtering by order number and time range but provides no guidance on when to use this tool versus alternatives such as QuerySmallAssetList or QueryOrderByPage. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does provide a rate limit ('5 req/s (UID)') and implies a mutating action, but it does not mention side effects, permission requirements, reversibility, or what happens to the accumulated interest after reinvestment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: one clear action sentence plus a rate-limit line. There is no filler, repetition, or buried critical 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 4-parameter write operation with no output schema and no annotations, this description is too thin. It omits parameter semantics, request/response expectations, prerequisites, and alternative routing, leaving the agent to infer too much about how to invoke the tool correctly.
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%, and the description does not explain any of the four parameters: leverage, productId, positionId, and orderLinkId. An agent must rely entirely on parameter names, with no guidance on required semantics or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('reinvest') and a specific resource ('accumulated interest' into an 'existing Liquidity Mining position'), making the core action clear. It is distinct from siblings like addLiquidity or claimLiquidityInterest, but it does not explicitly name or differentiate from those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing implies this is for compounding earned interest into an existing position rather than adding new capital or claiming interest. However, there is no explicit when-to-use guidance, prerequisites, or mention of alternative tools, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states 'real-time position updates' but omits details like authentication needs, data frequency, subscription persistence, or how to unsubscribe. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core purpose. It is front-loaded with the key action and resource, with no superfluous text. However, it may be too terse given the tool's complexity.
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 subscription tool with no output schema and minimal annotations, the description lacks crucial context: how updates are delivered, subscription lifecycle (start/stop), or error handling. This is incomplete for an agent to use safely.
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 should explain parameters. It does not mention category, messageCount, or timeoutMs at all. The agent must infer meaning from names alone, which is risky for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'subscribe', the resource 'real-time position updates', and the scope 'Unified Trading Account (UTA)', distinguishing it from sibling subscribe tools like subscribeAdlAlert, subscribeDcp, etc.
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 (e.g., other subscription tools). The description does not mention prerequisites, contexts, or disclaimers, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that it's an OpenAPI interface with API key authentication, ACL permission, and rate limit. However, it does not describe return format, pagination behavior, or what happens with invalid parameters. The term 'confirmed' is not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with bullet points for additional info. Every sentence adds value. However, the lack of parameter details could be structured better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 0% parameter coverage, the description is incomplete. It covers auth and rate limits but fails to explain return values or param details. With many siblings, more contextual differentiation would help.
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 coverage is 0%, so description must add meaning. It only explains accountType as 'comma-separated', but does not describe index or limit parameters. No examples or value constraints are given. This leaves agents guessing about parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries confirmed conversion records, with verb and resource. It mentions support for multiple wallet types and comma-separated accountType. While it doesn't explicitly distinguish from siblings like SmallAssetConvert, the name and description imply a read-only historical query, which sets it apart from execution 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 mentions authentication and rate limits but provides no guidance on when to use this tool over alternatives (e.g., CoinConvertLimitQuery, ConvertExecute). There are no exclusions or context about prerequisites 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the authentication requirement but lacks details on subscription behavior (e.g., persistent vs one-time, data format, side effects). With no annotations, the description carries the full burden, which 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. It is appropriately concise but omits critical information, balancing brevity and completeness poorly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but the description fails to explain the subscription mechanics, what 'Greeks' data includes, or how to use the output. Sibling tools suggest varied subscription behaviors, but this description provides no differentiation.
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%, and the description does not mention the two parameters (messageCount, timeoutMs) or their meaning, leaving the agent with no additional context beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '订阅' (subscribe) and resource 'Greeks' to clearly indicate the tool's purpose. It distinguishes from sibling subscribe tools which target different data streams (e.g., subscribeAdlAlert, subscribeKline).
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 states a prerequisite (authentication required) but provides no guidance on when to use this tool versus alternatives (e.g., other subscribe tools) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds significant behavioral context: it requires API Key authentication, specifies ACL permission (RESOURCE_GROUP_EXCHANGE_HISTORY + PERMISSION_READ), rate limits (30/user/s, 1500/path/s globally), and a compliance review requirement (CONVERSION product). This information helps the agent understand the tool's constraints and safety profile, though it does not explicitly state that the tool is read-only (implied by 'query').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using 5 lines to convey purpose and key behavioral traits. It front-loads the action and then lists requirements in a clear manner. No redundant information is present, though a more structured format (e.g., bullet points) could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and 3 input parameters, the description is incomplete. It does not explain the return format or the meaning of all parameters (side and coin are not elaborated). For a query tool, the user would benefit from knowing what data is returned (e.g., list of coins with types), which is missing.
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 coverage is 0%, so the description should compensate by explaining parameters. However, it only vaguely mentions 'account type and conversion direction' without detailing the enum values for accountType or the meaning of side (0/1) and coin. This adds minimal value beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries a convertible coin list under specified account type and conversion direction, providing a specific verb+resource. However, it does not explicitly differentiate from similar sibling tools like 'queryCoinList', though the purpose is distinct enough given the mention of conversion direction.
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 lacks guidance on when to use this tool versus alternatives. It provides context on authentication, permissions, and rate limits, but no explicit when-to-use or when-not-to-use instructions, nor does it mention any alternative tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions a rate limit (10 req/s) and cursor-based pagination, but does not explicitly state that the tool is read-only, describe any side effects, or indicate required permissions. The word 'Query' implies a read operation, but more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with a rate limit note, front-loaded with the core functionality. No unnecessary words or repetitions.
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 6 parameters, no output schema, and no annotations, the description is incomplete. It fails to explain parameter meanings, return format, or provide usage examples, leaving 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not explain any of the 6 parameters (baseCoin, quoteCoin, startTime, endTime, limit, cursor). It only mentions cursor-based pagination in passing, leaving the agent without context for what each parameter does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries liquidation records for Liquidity Mining positions with cursor-based pagination. It distinguishes from sibling tools like getLiquidityMiningOrders and getLiquidityMiningPositions by specifying 'liquidation records'.
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 liquidation records but provides no explicit guidance on when to use this tool versus alternatives or any prerequisites. The context is clear from the name and description, but no specific when-to-use or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions rate limit (20 req/s IP) and lack of authentication, which affects the userQuota field. However, it does not state whether the tool is read-only or describe error handling or return format, leaving gaps despite no annotations to cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very concise (two sentences plus rate limit) with no fluff. Purpose is front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description lacks information on parameter usage, response structure, and potential pagination. Given one optional parameter and no output schema, more context is needed for effective use.
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 sole parameter 'coin' has no schema description and the tool description does not explain its purpose. With 0% schema coverage, the description fails to add meaning; it is unclear if it filters products or is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries a list of RWA products and enumerates specific metadata fields (APR, NAV, stake limits, precision), distinguishing it from sibling tools like getRwaOrderList or getRwaPositionList.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only lists behavioral info (rate limit, authentication) but does not specify use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses potential latency during extreme volatility and clear date range behavior, which is helpful. However, it does not mention authentication, rate limits, pagination behavior, or what happens with large result sets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and a note. It is front-loaded with purpose. However, the volatility note could be integrated into the rules or placed at the end. Still, it is reasonably concise for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 6 parameters, the description is incomplete. It thoroughly explains time range behavior, but omits parameter details (symbol, limit, cursor) and return format. An agent would need additional documentation to use this tool effectively.
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 coverage is 0%, meaning the input schema provides no descriptions. The tool description only mentions the 'category' parameter (linear) and implicitly the time range parameters through the rules. It fails to explain 'symbol', 'limit', 'cursor', or format of time parameters (e.g., Unix timestamp). This leaves the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries session settlement records for USDC perpetual contracts (linear). It specifies the scope (USDC contracts) and distinguishes from other query tools by the type of data (settlement records). However, it doesn't differentiate from other 'get' tools that might also return historical data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed time range rules and latency warnings, but does not explicitly state when to use this tool vs alternatives. Usage context is implied by the tool's purpose, but there is no guidance on scenarios where other tools might be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It accurately implies a read-only operation with 'Retrive' and adds the important account-type constraint 'Unified account only,' but it does not disclose authentication needs, error cases, currency format issues, or the exact shape of the returned value.
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 very concise, front-loaded with the primary action and resource, and the 'Unified account only' constraint is stated in a separate clear line. There is no redundant wording or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only endpoint, the description conveys the core semantics and a key precondition. However, because there is no output schema and no annotation, it leaves out the return type and currency format, and it does not route the agent away from similiar crypto-loan or fixed-inventory 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%, and the description only says 'for a specified cryptocurrency,' which largely restates the parameter name 'currency.' It does not provide the expected format, valid values, or examples, so the agent must guess whether to pass 'BTC', 'BTCUSDT', or another identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Retrieve'), the resource ('flexible available inventory'), and the scope ('spot margin trading'). It also clarifies what the inventory means with the parenthetical 'remaining borrowable amount from the lending pool,' but it does not explicitly distinguish itself from similiar sibling tools such as getCryptoLoanFlexibleAvailableInventory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to prefer this tool over alternatives like getSpotMarginTradeMaxBorrowable or queryFixedAvailableInventory. The 'Unified account only' note is a useful constraint but not enough to help an agent choose among the many similiar inventory-query siblings.
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 should disclose behavioral traits. It only mentions a rate limit of 20 req/s. It does not state whether the tool is read-only, idempotent, or what happens if a position does not exist. The rate limit is useful but insufficient to fully characterize 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 very concise with two sentences. The first sentence clearly states the tool's purpose, and the second provides a rate limit. There is no extraneous information. However, it could benefit from structuring as a bullet or including a brief note on the response type.
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 one parameter, no output schema, and low complexity, the description is mostly complete. It states the tool returns a position and yield summary and provides a rate limit. However, it lacks details on the structure of the yield summary and whether the position includes open/closed status. Some context is missing for a fully informed call.
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 required parameter 'coin' with enum ['BYUSDT']. Schema coverage is 0% because the description does not explain the parameter. However, the enum and tool name make the parameter obvious. The description adds no additional meaning beyond the schema, so it does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the user's BYUSDT Token position and yield summary. The verb 'Query' and the specific resource 'BYUSDT Token position and yield summary' are unambiguous. It distinguishes from sibling tools like getTokenDailyYield or getTokenOrderList by focusing on the combined position and yield summary for a specific token.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusionary criteria. The only operational detail is the rate limit, which does not help with 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.
Behavior3/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 discloses that non-zero assets are not returned by default, and mentions UTA manual borrow logic and potential latency. It does not cover other behavioral aspects like idempotence, error states, or output format, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a main sentence with bullet points and notes. It is moderately structured but includes some redundancy and could be more concise. Notes add valuable context but increase length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially explains what the tool returns (per-currency info, risk rate) and includes important notes. However, it lacks details on pagination, error handling, and the exact format of the response, reducing completeness for 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 description must explain parameters. It states accountType is UNIFIED and coin is optional, but does not explain the effect of the coin parameter or how it modifies the output. The meaning of parameters is minimally conveyed.
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 obtains wallet balance with per-currency asset information and risk rate. It distinguishes from funding wallet by referencing a separate endpoint. However, it does not explicitly differentiate from similar sibling tools like queryBalance or getAccountInfo.
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 mentions that for Funding wallet balance a separate endpoint should be used, providing some guidance on when not to use. However, it lacks explicit when-to-use guidance versus other balance-related tools and does not specify prerequisites or contexts of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that authentication is required ('需要鉴权'), which is a critical behavioral trait. However, it does not mention whether the subscription is persistent, how to stop it, rate limits, or event frequency. With no annotations, this is a minimal but incomplete disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and the subscription nature, the description fails to explain how the tool works (e.g., persistent vs. poll), what events are returned, or how to use parameters. Sibling tools suggest subscription behavior, but the description offers no context for a complete understanding.
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%, and the description does not mention any parameters (messageCount, timeoutMs). It provides no additional meaning beyond the input schema, leaving the agent to infer parameter usage without context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool subscribes to Spread order changes, specifying the exact resource ('Spread order') and action ('subscribe'). It distinguishes from sibling subscribe tools like subscribeOrder and subscribeSpreadOrderbook by specifying 'Spread order' rather than generic orders or other spread data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only states what it does, with no mention of scenarios where this is appropriate or exclusion of other subscribe 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 provided, so description carries full burden. It mentions rules (variable rate, manual, Unified account) but lacks details on consequences of borrowing, interest specifics, response format, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and to the point, using bullet points for rules. No redundant words, though it could be slightly better organized with parameter explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema provided. Description omits prerequisites, effect on account, and how to interpret the response. For a mutation tool, more context is needed.
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 has 2 parameters (coin, amount) with 0% description coverage. Description does not explain what coin or amount represent (e.g., symbol, units, decimal precision), leaving the agent without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for manual borrowing on a Unified account, with specific rules (variable rate only, manual operations only). This distinguishes it from sibling tools like accountFixedBorrow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use: for manual, variable rate borrowing on Unified accounts. It implies when not to use (e.g., fixed rate or automated), but does not explicitly mention alternative tool accountFixedBorrow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a rate limit of 50 req/s, which is a behavioral trait. However, without annotations, it does not state that the operation is read-only (though 'Query' implies it) nor disclose other behaviors like authentication needs or error handling. The description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no redundant information. It front-loads the purpose and rate limit. Loses a point for lack of structure (e.g., no separation of parameter info) but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 parameters with no description coverage, the description should have provided more details on return format, possible filters, or default behaviors. The vague 'etc.' leaves gaps, making it incomplete for a query tool.
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?
With 0% schema description coverage, the description fails to explain the parameters. It only mentions the output fields, not what accountId, awardId, specCode, or withUsedAmount mean. This leaves the agent without semantic context for selecting parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Query' and the resource 'voucher distribution records', listing specific fields like claim status, validity period, and consumed amount. This specificity distinguishes it from sibling tools, which are also query tools but for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The sibling tool list is extensive but the description provides no context for selection, no prerequisites, and no when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses default and maximum query range and pagination. It implies a read operation ('Query'), but does not explicitly state safety or side effects. This is adequate but could be improved with explicit read-only indication.
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 3 short lines. It front-loads the purpose and then lists key constraints and features. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no annotations, the description is insufficient. It omits details on parameter meanings, pagination usage, and potential filtering options. The tool is relatively complex and the description does not cover its capabilities adequately.
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%, and the description only implicitly relates to time parameters via the default range. It does not explain the category, orderId, orderLinkId, productId, startTime, endTime, limit, or cursor parameters. Given 8 parameters, the description should provide more parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries stake/redeem order history. The verb 'Query' and resource 'Earn Order History' are specific. Although it doesn't explicitly distinguish from sibling 'getOrderHistory', the name and mention of 'stake/redeem' differentiate it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage constraints: default 7-day range and max 7-day range, plus pagination support. However, it does not give explicit guidance on when to use this tool versus alternatives like 'getOrderHistory' or other order querying tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but discloses no behavioral traits beyond its function (e.g., read-only status, authentication needs, pagination, rate limits). Only states what it returns without deeper behavior context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with a clear front-loaded purpose and an agent hint. Minor redundancy in 'AI agent can use this...' sentence, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers high-level purpose and some return fields, but lacks details on response structure, error handling, or prerequisites. The tag-schema mismatch reduces completeness. No output schema exists to compensate.
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?
Description mentions tokenSymbol filtering and implies it's optional, but incorrectly adds a 'tag' parameter not in schema. Does not explain acceptable values or format for tokenSymbol, so adds partial but misleading value.
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?
Clearly states the tool queries available liquidity pools with optional filtering and lists returned fields (addresses, tokens, APY, TVL). However, it mentions filtering by 'tag' which is not in the schema, causing confusion, and does not explicitly distinguish from sibling tools like getLPPoolInfo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an agent hint specifying when to use (browsing/searching pools by token) and how to filter. Lacks explicit when-not-to-use instructions or alternatives such as getLPPoolInfo for detailed pool info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds meaningful details beyond the schema: authentication is required, and the returned available balance (`ab`) is truncated to 8 decimal places, not rounded. This is genuinely useful behavioral information, though the full response shape is not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one clear purpose sentence followed by two relevant bullet notes. Every sentence contributes useful information and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description must be fairly complete on its own. It covers authentication and decimal truncation, but it omits the meaning/role of `orderPrice`, the interpretation of the side enum, and the overall response format. This leaves an agent with important gaps when trying to invoke the 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, but it only restates 'symbol' and 'side' without clarifying the meaning of the side enum values ('1' vs '2'). The required `orderPrice` parameter is not explained at all, leaving a significant semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Query') and the resource ('spread wallet available balance'), and ties it to a symbol and side. It does not explicitly contrast this tool with related siblings like getWalletBalance or queryBalance, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of when not to use it. The authentication note is a precondition, not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses rate limit (5 req/s UID), parameter constraints (autoInvest only for FundPool, orderLinkId idempotency), and a hint that it locks funds. However, it doesn't mention return values, irreversibility, or authorization requirements. With no annotations, the description carries full burden but remains incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear main clause, bulleted notes, and a separate hint. The critical warning about locking funds is placed at the end, but overall structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 6 required, 2 enums, no output schema, and no annotations, the description is incomplete. It lacks parameter details, return value info, and comprehensive behavioral traits for a mutative operation with significant consequences.
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?
Only two of seven parameters are explained (autoInvest and orderLinkId). The schema has 0% description coverage, so the description should compensate but fails to explain productId, category, coin, amount, and accountType.
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 'Place a staking order for a fixed term product', specifying the verb (place) and resource (staking order for fixed term). It distinguishes from sibling tools like placeEarnOrder, which likely handle flexible terms.
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 placeEarnOrder or placeAdvanceEarnOrder. The agent hint focuses on user confirmation, not on tool selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only indicates a state change but does not disclose side effects, reversibility, permissions needed, or any other behavioral traits. With no annotations, the description carries full burden for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded and 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 toggle with one enum parameter, the description provides the core function. However, it lacks context about the meaning of 'PM include spot hedging mode' and any prerequisites, making it minimally 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 description indirectly explains the parameter by stating enable/disable, which aligns with the ON/OFF enum. Though schema coverage is 0%, the parameter name and enum values make the meaning clear, and the description adds 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 clearly states the action (enable/disable) and the target resource (PM include spot hedging mode). It is specific enough to distinguish from sibling tools like setMarginMode, but the jargon may confuse agents unfamiliar with trading terminology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of prerequisites, context, or scenarios where the tool is or is not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation by using 'Query' and 'Returns', but does not explicitly state it is safe or disclose any other behavioral traits like authentication or rate limits. With no annotations, minimal transparency is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but contains redundancy: 'Returns token details and user's available balance for each.' is repeated later. The 'Agent hint' sentence is extra. It could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It does not specify the structure of token details, how parameters affect results, or any prerequisites. The tool is simple but the description lacks depth.
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% and the description does not explain the two parameters (chainCode, tokenAddress). It fails to add any meaning beyond the schema, which is a significant gap for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries available payment tokens for LP staking, returns token details and user's available balance. It distinguishes itself from siblings like getPayTokenList by specifying 'LP staking'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Call this before staking to show users which tokens they can use.' It does not explicitly mention alternatives or when not to use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'Get detailed information' without specifying what 'detail' entails, such as included fields or data freshness. No mention of rate limits, authentication, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, front-loaded with purpose. However, could include more substance without losing conciseness, such as listing key returned fields.
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?
Simple tool with no output schema, so description should hint at response structure. It does not mention what 'detailed information' includes (e.g., status, amount, timestamps). Lacks completeness for an agent to anticipate return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (orderId) with 0% schema coverage. Description implies it identifies the specific order but adds no format or constraints beyond the schema. Adequate but minimal value over basic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves detailed information for a specific P2P order. Verb 'Get' and resource 'detailed information of a specific P2P order' are well-defined. Distinct from list-based sibling tools like getOrderList or getAllOrders.
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?
Implies usage for obtaining details on a single order via orderId, but no explicit guidance on when to choose this over similar tools (e.g., getOrderList, getOrderHistory). No context about prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses default and maximum time range, which is useful. However, with no annotations, the description does not cover behavior like pagination, read-only nature, or rate limits. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. No wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, 2 required, no output schema, and no annotations, the description covers only the time range. Missing details on filtering, pagination, and return structure. Incomplete for effective tool use.
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 coverage is 0%, and the description adds no explanation for any of the 7 parameters (status, beginTime, endTime, tokenId, side, page, size). Agents must infer meaning from names alone, which is insufficient.
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?
Clearly states the action (get a list), the resource (pending P2P orders), and provides specific scope (default 90 days, max 180 days). Distinguishes from sibling tools like getAllOrders by specifying 'pending P2P orders'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for pending P2P orders, but offers no explicit guidance on when to use this versus alternatives like getOpenOrders, getOrderList. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions return fields (teams, time, status, prediction markets) but does not disclose limitations (e.g., max matches, pagination) or clarify that filtering by matchStatus is a client-side operation since the input schema only includes eventType. With no annotations, the description bears full burden but is incomplete.
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 mostly efficient, with front-loaded purpose and structured hints. However, the filtering advice 'Filter by matchStatus' is placed in a hint yet is not supported by the schema, introducing unnecessary confusion. Otherwise, sentences are concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must detail return values. It mentions teams, time, status, and prediction markets but lacks specifics like field names or types. More critically, it advises filtering by matchStatus despite the schema having no such parameter, creating a dangerous mismatch. This is insufficient for an agent to use the tool reliably.
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 coverage is 0% for the only parameter eventType. The description adds the example 'eventType=1 for FIFA 2026' but does not explain the parameter's meaning generally or note that it is fixed to '1' per the schema enum. This is insufficient compensation for the lack of schema-level 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 it queries all matches for a sports event with status and prediction market info. However, it also suggests filtering by matchStatus, which is not a parameter in the input schema, creating ambiguity about the tool's actual capability. The verb 'Query' and resource 'matches' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: showing available matches to bet on, and points to related tools like getPredictionEventDetail. It gives filtering hints for matchStatus and advises against showing Ended matches. However, it does not clearly differentiate from other prediction tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions rate limit and auth, but there is ambiguity about 'user's FlexibleSaving balance' given 'No authentication required' – it's unclear how user-specific data is accessed without authentication. This lack of clarity lowers transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loading the purpose. The rate limit and auth info are included without excess. Could be slightly more structured, but it's efficient and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param, no output schema), the description covers the basic purpose, rate limit, and auth. However, it fails to explain the user-specific data without auth and does not describe the response format, leaving some gaps. It is moderately complete.
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 schema has 1 parameter (coin) with 0% description coverage. The description does not add any information about the parameter, even though the enum limits to 'BYUSDT'. It fails to compensate for the low coverage, leaving the parameter undocumented in prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Query BYUSDT Token product details' and lists specific fields (FlexibleSaving balance, remaining quota, APR), making the purpose specific and distinguishable from sibling tools like getTokenPosition or getTokenDailyYield.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides rate limit and auth requirements ('No authentication required'), but does not explicitly guide when to use this tool versus alternatives (e.g., other getToken* tools or getProduct tools). The usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It adds useful context that withdrawable amounts may be partially frozen due to pending on-chain deposits or risk review, which helps the agent interpret returned values. It also indicates the return covers FUND and UTA accounts, though it does not mention authentication, rate limits, or exact response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. The bullet points add meaningful caveats without unnecessary filler, and every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool, the description covers the main purpose, the account types, and an important freeze caveat. However, with no output schema, no parameter format details, and no usage guidance relative to similar tools, it leaves meaningful gaps for an agent deciding how to call it and interpret the response.
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 should compensate by explaining the coin parameter. It only says 'for a specific coin,' which adds little beyond the schema's property name. No format, examples, or valid value conventions are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get'), a resource ('withdrawable amount for a specific coin'), and explicitly names the account types covered (FUND and UTA). It does not explicitly distinguish itself from sibling tools like getAccountWithdrawalInfo or getWalletBalance, but its scope is specific enough to be recognizable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of related wallet/withdrawal tools. There are no alternative tool names, exclusions, or contextual triggers mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the tool does not place orders, returns pre/post margin rates in E4 format, and only works for linear and option categories. It does not mention authentication, rate limits, or detailed response structure, but covers key behavioral aspects adequately.
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 somewhat repetitive with an Agent hint and TradFi note that restate the same core information. It could be streamlined into a single concise paragraph without losing 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 21 parameters, no output schema, and no annotations, the description is insufficient. It fails to explain the response format in detail, provide parameter guidance, or cover prerequisites. The tool is moderately complex but the description only addresses basic purpose.
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 coverage is 0% with 21 parameters. The description only states 'Request parameters are the same as Create Order' without explaining any parameter meaning, format, or constraints beyond what enums provide. This fails to add value for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates an order before placing it to check margin requirements. It specifies it is for futures and options only (linear, option categories) and distinguishes itself from createOrder by noting it does not actually place the order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this endpoint to validate margin requirements before placing an order, and that it does not create orders. It states only works for futures and options, implying not for other categories, but could be more explicit about when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must cover behavioral traits. It discloses a rate limit constraint, which is valuable. However, it does not mention other important aspects such as authorization requirements, side effects (e.g., ad visibility during update), or whether changes are reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences), front-loads the core function, and adds a specific constraint without unnecessary words. Every sentence serves a 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 complexity (12 required parameters, nested object, no output schema), the description is insufficient. It does not explain the purpose of key parameters, the meaning of 'relist,' or what the response contains. The rate limit note is helpful but does not compensate for the overall lack of detail.
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%, so the description should compensate. It provides no information about the 12 parameters (e.g., price, premium, actionType enums). The description fails to add any meaning beyond the raw schema, leaving the agent without guidance on how to set parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update or relist a P2P advertisement.' This specifies both the verb (update/relist) and the resource (advertisement), and implicitly distinguishes it from sibling tools like 'postAd' (create) and 'removeAd' (delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a rate limit note (max 10 modifications per 5 minutes), but lacks explicit guidance on when to use this tool versus alternatives such as 'postAd' or 'removeAd'. It does not state prerequisites or when not to use it, leaving ambiguity for the agent.
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 provided. The description lacks behavioral disclosure such as idempotency, rate limits, or authorization requirements. It only mentions the master API key restriction for sub query, but does not state it is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three sentences and three bullet points. Information is front-loaded and every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 4 params with 0% schema coverage, the description covers the core purpose and key parameters but lacks behavioral details and does not describe the return format. Adequate for a simple query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description carries burden. It explains accountType (required), coin (required for UNIFIED, comma-separated), and memberId (sub account). However, withBonus is entirely unexplained, leaving a gap.
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 'Query coin balances across a single account type' with specific support for sub UID balance via master API key. It distinguishes itself from related tools like accountCoinBalanceQuery, but does not explicitly name siblings.
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?
Provides useful context: 'accountType is required', 'For UNIFIED account, coin is required', and 'memberId is used to query sub account balance (master API key only)'. However, it does not discuss when not to use this tool or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It warns that the tool places real orders and that the response is not a confirmation. It does not disclose potential issues like partial batch failures, execution order within the batch, or rate limits, which are important for a batch tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a warning paragraph. It front-loads the purpose and provides critical usage guidance without unnecessary detail. Every sentence adds value.
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 (array of 20+ fields per order, batch execution, no output schema), the description lacks information on batch behavior (atomicity, error handling, ordering), prerequisites (e.g., WebSocket connection), and the exact nature of 'modify' claims. It is incomplete for a tool that can have significant financial impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the baseline is 3. The description does not add parameter-specific semantics beyond the schema; it only references confirming symbol, side, quantity, and price, which are already documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: batch placing multiple orders via WebSocket on Bybit V5 unified account. It distinguishes from similar tools like wsCreateOrder (single order) and batchCreateOrders (REST) by specifying the WebSocket transport. The verb 'place' matches the tool name, though 'modifies' is slightly ambiguous for a create-only tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises confirming order details with the user before calling and notes that the response is only an acknowledgment, recommending subscribeOrder or REST endpoints for verification. However, it does not explicitly state when to use this tool vs its siblings (e.g., REST batchCreateOrders) or provide exclusions for unsupported order types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds value by stating a rate limit (50 requests/second) and the behavior that using rfqId cancels all quotes for that RFQ. However, it does not disclose other traits like irreversibility, authorization needs, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly concise but includes redundant agent hint that repeats the parameter info. The rate limit note is helpful but could be integrated more efficiently. Overall, it is adequate but not tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, few parameters, and no annotations, the description covers basic usage and one behavioral note, but is incomplete regarding success/error responses, prerequisites, or broader context. It is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining the three parameters (quoteId, rfqId, quoteLinkId), their priority order, and the special behavior of rfqId. This adds significant meaning 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 tool cancels an active quote, using a specific verb and resource. It does not explicitly differentiate from sibling tools like cancelAllQuotes or cancelRfq, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a note on parameter requirements and priority order, but does not provide guidance on when to use this tool versus alternatives (e.g., cancelAllQuotes). It lacks explicit when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Provides rate limit (5 requests per UID), which is helpful. No annotations exist, so description carries full burden. Missing details on data freshness, read-only nature, or side effects. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence plus bullet points. Efficiently front-loads purpose. Every line adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing output schema and parameter descriptions. With 4 optional parameters and no annotations, description should clarify default behavior, return format, and pagination intricacies. Partially covered by feature list.
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 coverage is 0%, so description must compensate. It mentions query by order ID or currency and pagination, mapping to parameters loosely, but fails to explain input formats, valid values, or cursor mechanics. Minimal added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Query') and the resource ('historical flexible borrow records') with pagination. It differentiates from siblings like getCryptoLoanFlexibleRepaymentHistory by specifying 'borrow history'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like getCryptoLoanFlexibleOngoingCoin. The rate limit mention is a constraint but not usage direction. Missing when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacking annotations, the description explains time range behavior and account coverage, which are useful. However, it does not disclose read-only nature, authentication needs, or any side effects. For a query tool, this is acceptable but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using bullet points for time range rules for clarity. It is well-structured and front-loaded with the core purpose. Every sentence adds value, though it could be slightly more efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema or annotations, the description lacks completeness. It misses parameter explanations, return value description, and usage prerequisites. The time range rules are well-covered, but overall, the agent needs more context to use the 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?
With 0% schema description coverage, the description only indirectly explains startTime and endTime via time range rules. It omits explanations for category, symbol, expDate, limit, and cursor, which are in the schema. The description adds minimal semantic value for most 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 it queries delivery records of USDC futures, Inverse futures, and Options, and differentiates account types (Unified vs Classic). The verb 'Query' and resource 'delivery records' are specific and distinct from siblings like getTradeHistory or getOrderList.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed time range rules which guide when parameters are needed, but it does not explicitly state when to use this tool over alternatives or provide exclusions. No comparison with sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It mentions authenticated endpoint, return fields, precision, and optional filtering. Does not disclose rate limits, error cases, or data update frequency.
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?
Description is somewhat verbose with repeated information (e.g., margin rates precision mentioned twice). Structure is logical but could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema, description provides adequate detail on return fields and ordering. Covers core behavioral aspects for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
0% schema coverage; description explains the `currency` parameter (omit for all coins, pass to filter). Could add format or allowed values but sufficient for basic usage.
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?
Clearly states it queries position tier data for spot margin trading and lists return fields (borrow limits, margin rates, max leverage). No explicit sibling differentiation but purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides hint about authentication and optional filtering. Explains behavior when currency is omitted. Does not discuss when to use this tool vs other margin-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions authentication, permissions, and rate limit, but does not explicitly state if the operation is read-only or describe side effects. Since it's a query, it's likely safe, but the description could be more explicit about 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 well-organized with a main sentence followed by bullet points for key details. It is front-loaded with the purpose and provides useful context without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain what the response contains (e.g., list of orders). Parameters are not documented. The description lacks completeness for a paginated query tool.
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 4 parameters (cursor, limit, toCoin, fromCoin) with 0% description coverage. The description only mentions 'cursor pagination' but does not explain any parameter's meaning or usage. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it aggregates asset and OBU account data and queries conversion history orders by cursor pagination. It specifies the resource ('conversion history orders') and the operation ('query' with pagination), distinguishing it from other query tools like QueryOrderFromOpenApi.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides authentication requirements (API Key), ACL permission, and rate limit. It implicitly defines when to use (for conversion history queries) but does not explicitly exclude alternatives or compare with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses the parent-child validation and time range limit, but does not cover pagination behavior, rate limits, or that the operation is read-only. With no annotations, more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, uses bullet points for clarity, and front-loads the main purpose. It could be slightly more structured but is well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain what the response contains (e.g., fields, pagination details). For a query tool, this is a notable omission.
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?
Only subMemberId and time range parameters are explained via constraints; six other parameters (id, txID, coin, limit, cursor) are undocumented. With 0% schema coverage, the description leaves significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries on-chain deposit records for a sub-account using the main UID API key, distinguishing it from sibling tools like queryDepositRecords (for main account) and queryInternalDepositRecords.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides constraints (time range, required subMemberId) and a validation check, but does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose all behavioral traits. It mentions a rate limit of 1 req/sec and caller restrictions, but does not explain side effects (e.g., whether existing limits are overwritten), idempotency, or response structure. The behavioral disclosure is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and uses bullet points for rules. It avoids unnecessary words but could be slightly more compact. Every sentence adds value.
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 (nested array parameter, no output schema, no annotations), the description lacks completeness. It does not describe what the tool returns, whether the operation is atomic, or how to handle errors. The rules are helpful but not enough for full understanding.
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 coverage is 0%, so the description must compensate. It mentions 'specified UIDs' and 'rate limit' at a high level but does not explain the structure of the 'list' parameter or the meaning of 'bizType' and 'rate' fields. Parameter details are insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set API rate limit') and the resource ('specified UIDs under exchange broker account'). It distinguishes itself from sibling tools like setLeverage or setAutoAddMargin by specifying the broker account context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit rules for when to use this tool: only exchange broker accounts can call, and it explains master vs subaccount constraints. It does not mention alternatives or when not to use, but the rules are sufficient for basic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses time range limits but does not mention pagination behavior (cursor parameter not explained), required permissions, or side effects. The returned fields are listed, but overall behavioral details are incomplete.
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 4 sentences and front-loaded with the purpose, but contains redundancy (repeating 'Only applicable to option contracts' and 'Only category=option is supported'). It could be more concise by removing duplication and structuring information more efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description fails to fully inform. It lists some return fields but omits details on response structure, pagination, and error scenarios. The agent lacks sufficient context to invoke the tool correctly in all situations.
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 explains category and implies meaning for startTime/endTime via time range constraints, but does not describe symbol, limit, or cursor. Important parameters lack any explanation, leaving the agent uncertain about optional vs required usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries closed option position data and lists specific fields (entry/exit prices, fees, delivery details, realized PnL). The agent hint reinforces the purpose. It distinguishes from siblings by specifying it is for closed positions and options only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to retrieve closed option positions' and 'Only category=option is supported.' It also provides time range constraints (default 24h, max 7 days, 6 months history). However, it does not name alternative tools or state when not to use it, which would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavioral traits. It mentions pagination and polling behavior, but does not disclose rate limits, authentication needs, data freshness, or that it is read-only (though implied). The description is adequate but lacks explicit safety/cost disclosures that would be helpful.
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 front-loaded with purpose and key instructions, but there is significant repetition between the main description and the 'Agent hint' block. The hint recaps the do-nots and adds minor detail. The length is acceptable but could be trimmed by merging the hint into the main description, removing redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and no output schema, the description provides a general return value summary (order status, amounts, fees, time) and usage context. However, it does not explain pagination details, direction parameter semantics, or potential error conditions. It is moderately complete but leaves gaps for an agent to infer 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 coverage is 0%, so the description should add meaning for parameters. It only provides an example for orderStatus, but does not explain tradeType, tokenCode, days, limit, pageIndex, or direction. Without parameter descriptions, the agent may misuse or misunderstand the filters. The example helps slightly but insufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries order history with optional filters and returns paginated data including specific fields. It distinguishes itself from getBizTokenPriceList and getAssetList, but does not differentiate from similar order list tools like getOpenOrders or getPendingOrders, which are numerous in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Excellent guidance: explicitly states when to use (after executing a trade to confirm result) and when not to use (do not for token prices or asset holdings), with specific alternative tool names. Also provides a concrete polling scenario using orderStatus filter. This fully equips the agent to decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It states it is a read operation and specifies the unified account requirement. However, it does not disclose potential rate limits, authentication needs, or the structure of the returned 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 very concise: two sentences with a clear bullet point. Every sentence adds value with no redundant 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 simple input schema and no output schema, the description covers the core behavior and constraints. However, it omits details about the return format or error scenarios, which would be helpful 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?
The schema has 0% coverage, so the description compensates by explaining that omitting currency returns all coin states. This adds meaning beyond the raw schema, but it does not specify valid currency formats 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 tool retrieves spot margin leverage information for cryptocurrencies, with a specific verb and resource. It also notes the unified account requirement and the behavior when currency is omitted. However, it does not explicitly differentiate from sibling tools like getSpotMarginTradeState.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that the tool is for unified accounts only and explains the optional currency parameter's effect. However, it lacks explicit guidance on when not to use this tool or mention alternatives for non-unified account scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries behavioral burden. It discloses the 30-day window, status filter meanings, and API key accessibility. However, it does not mention pagination behavior (cursor), rate limits, idempotency, or what happens with invalid 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 extremely concise with three bullet points, no wasted sentences, and important details front-loaded (platform scope, accessibility, time window).
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 0% schema coverage and no output schema, the description is incomplete. It covers some constraints but omits parameter details for 4 out of 7 parameters, return format, and error handling. The tool's complexity (7 parameters) demands more comprehensive explanation.
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 coverage is 0%, so description must explain parameters. It only explains the 'status' parameter values and the time window constraint for startTime/endTime. Other parameters (txID, coin, cursor, limit) are not described, leaving significant gaps for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries deposit records within the Bybit platform, distinguishing it from on-chain deposit queries (e.g., queryDepositRecords). The verb 'Query' and resource 'deposit records' are specific, and the platform scope is explicitly highlighted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful constraints: accessible via Master/Sub Member API Key, max 30-day window, defaults to last 30 days. However, it lacks explicit when-to-use guidance compared to sibling tools like queryDepositRecords, and does not describe when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses auth method (API Key), ACL permission, and rate limit (100/path/s globally), which are beyond the tool name. However, it doesn't mention if the query is read-only or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences plus three bullet points) and front-loaded with the purpose. The extra operational details are useful but could be integrated more concisely. No unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description fails to mention what the tool returns (min/max limits). It also doesn't explain why one would query limits (e.g., before a conversion). The 5 parameters are only partially addressed, leaving gaps for an agent to interpret.
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%, but the description only vaguely mentions 'coin pair' and 'account type'. It does not explain the meaning of fromCoinType and toCoinType enums (0/1) or clarify that the limits are min/max quantitatively. The description adds little value over parameter names.
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 'query single conversion min/max limit for specified coin pair under specified account type', specifying the verb (query), resource (conversion limit), and scope (single pair, account type). It distinguishes from sibling tools like ConvertExecute and ConvertHistoryQuery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes authentication, permission, and rate limit info but does not explicitly state when to use this tool versus alternatives or provide usage conditions like prerequisites or when-to-avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that no authentication is required and specifies a rate limit, which is useful for a query tool. However, it does not mention any potential side effects or other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise: two sentences covering purpose, authentication, and rate limit. It front-loads the core purpose immediately, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not elaborate on the return format. While the purpose is clear, a query tool without output schema could benefit from hints about the response structure. However, the context signals (no nested objects, simple params) keep the tool relatively straightforward.
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 has 3 parameters (category, coin, duration) with 0% schema description coverage. The tool description adds no explanation of their meaning or format. This leaves the agent with insufficient information to correctly specify parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Query available Advance Earn product listings', which clearly identifies the verb ('Query') and the resource ('Advance Earn product listings'). The resource is specific and distinct from sibling tools like getEarnProduct or getFixedTermProduct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides authentication and rate limit info ('No authentication required. Rate Limit: 50 req/s (IP)'), but lacks explicit guidance on when to use this tool over similar sibling tools like getEarnProduct or getTokenProduct. Context is partially implied by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds some behavioral info like returning realized P&L and final outcomes (WIN/LOSE/MANUAL_CLOSE). However, it does not disclose pagination behavior or authentication needs, which are important for a query tool with pagination parameters.
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 has redundancy, repeating the result format in multiple sentences. While not overly long, it could be more concise by merging the agent hints and result description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and pagination parameters, the description is incomplete. It mentions result content but omits pagination behavior, direction meaning, and any error conditions. The distinction from getPredictionPositionList is helpful, but more details are needed for full context.
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%, and the description does not explain the three parameters (limit, direction, pageIndex) at all. The agent must infer their meaning from names alone, which is insufficient for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the authenticated user's historical prediction positions that have been closed, specifying the verb, resource, and scope. It distinguishes itself from the sibling tool getPredictionPositionList, which handles open positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to use getPredictionPositionList for open positions, and provides context for summarizing trading performance. It lacks explicit when-not-to-use conditions but offers clear guidance on alternative usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Retrieve' to indicate a read operation but does not disclose any potential side effects, auth requirements, rate limits, or how the borrowable amount is determined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two lines: first line states the purpose, second line adds a constraint. It is concise, front-loaded, and contains no redundant 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 simplicity (single parameter, no output schema), the description covers the essential purpose and a key constraint. However, it lacks details on what factors influence the result or the format of the return value.
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 description mentions 'specified cryptocurrency' which refers to the 'currency' parameter, but schema coverage is 0%. The description adds minimal meaning beyond the parameter name, lacking details on format or allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'maximum borrowable amount for a specified cryptocurrency in spot margin trading'. It also includes a specific constraint 'Unified account only', distinguishing it from sibling tools like getSpotBorrowQuota.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions 'Unified account only', setting a clear precondition. It does not, however, specify when not to use this tool or compare it with alternatives like getSpotBorrowQuota.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses behavioral traits: it returns up to 2 years of data, has a rate limit of 5 req/s, defaults time range to last 24h, enforces a 7-day span with both times, uses cursor pagination, and limits to 50 per page. This provides sufficient transparency for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear first sentence stating the main purpose, followed by a bullet-like agent hint that adds specific usage details. It front-loads key information without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no annotations, the description covers essential usage and constraints but falls short on explaining all parameters and the structure of the response (e.g., fields returned). This warrants a mid-range score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It explains category (with enum values), currency, type, time range, limit, and cursor. However, it omits accountType (only UNIFIED, but no context), baseCoin, and transSubType, leaving gaps for 4 out of 10 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 that the tool queries unified account wallet transaction logs with filtering capabilities. It specifies the resource ('transaction logs') and action ('Query'), distinguishing it from other tools that deal with orders or trades, though it doesn't explicitly differentiate from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides hints on when to use the tool ('Use this to retrieve detailed wallet transaction history') and outlines filtering options, default time range, and pagination. However, it lacks when-to-use alternatives, such as comparing it to getOrderHistory or getTradeHistory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It describes the balance fields and parameters, but it does not mention whether the tool is read-only, any authentication needs, rate limits, or data freshness. It does not contradict any annotations since none exist, but it lacks depth for a fully transparent description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for query parameters, balance information, and use cases. It is concise without being overly terse. The most important information (purpose and parameters) is front-loaded. A minor improvement would be to combine the use cases into the purpose statement to save lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description does a good job of explaining what the tool returns (total, available, frozen balances). It also covers the use cases. However, it does not mention if the response includes additional fields or any pagination. Overall, it is comprehensive enough for a simple balance query, but could be slightly more detailed about the response structure.
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% coverage, meaning the schema provides no descriptions. The description compensates by explaining both parameters: accountCategory (enum with default) and currency (omit for all). It adds meaning beyond the schema. However, it does not specify the format of the currency code (e.g., ISO 4217), leaving a small gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool queries fiat or crypto account balances, and it lists the returned balance fields (totalBalance, balance, frozenBalance). It also provides use cases, which helps understand its purpose. However, it does not distinguish itself from sibling tools like getWalletBalance or getAssetDetail, so the clarity is good but not excellent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (display before trading, validate funds, show breakdown), which indicates when to use the tool. However, it does not mention when not to use it or suggest any alternatives. Given the large number of sibling tools with overlapping functionality, this lack of exclusion or comparison is a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses required parameters, format constraints (uppercase currency), supported coins, formula for inventory, precision handling, and account type restriction. This provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a heading and bulleted rules. It is concise, informative, and front-loads the main purpose. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the inventory formula, precision details, and account restrictions. However, since there is no output schema, it lacks explanation of the return structure. For a query tool, this is a notable gap, but the formula partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions in schema). The description adds that all parameters are required, currency must be uppercase with examples, and implies coins must be supported. However, 'term' and 'annualRate' lack additional semantic detail beyond being required strings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Query available inventory for fixed-rate borrowing' with specific parameters, clearly indicating the action and resource. It does not explicitly differentiate from sibling tools like 'getCryptoLoanFixedBorrowOrderQuote' or 'queryFixedBorrowMarket', but the purpose is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (e.g., before borrowing) but does not explicitly state when to use this tool versus alternatives. No 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the essential behavior (toggling auto-reinvestment) and a rate limit. However, it lacks details on outcomes (e.g., success/failure responses), error handling when the product doesn't support auto-reinvestment, or other side effects. The transparency is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single-line action summary, a one-line note, and a rate limit. It is front-loaded with the core purpose and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides the core information (purpose, precondition, rate limit). However, it lacks parameter descriptions, return value expectations, and error scenarios. For a state-changing tool, more completeness would be beneficial, but the description covers the essentials.
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%, and the description adds no explanations for the four parameters (productId, category, positionId, status). The parameter names and enums are somewhat self-explanatory, but the description fails to compensate for the missing schema details, especially the meaning of the category and status enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Enable or disable auto-reinvestment for a fixed term position.' The verb is specific (enable/disable) and the resource is well-defined (auto-reinvestment for a fixed term position). It distinguishes itself from siblings by focusing on auto-reinvestment toggling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a condition for usage: 'Only applicable for FundPool products that support auto-reinvestment.' However, it does not explicitly state when not to use this tool or offer alternatives for cases where the condition is not met. The usage context is implied but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behavioral traits: differences in queryable records by API key type and default time range. However, it does not mention pagination, rate limits, or whether the operation is read-only. The description adds some value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise (3 sentences plus bullet) and front-loads the main purpose. It uses bullet points for key distinctions. No wasted words, but could be slightly more compact.
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 7 parameters, no output schema, and no param descriptions, the description is incomplete. It does not cover pagination, filtering parameters, or response format. For a query tool, more context on result structure and use of cursor/limit is needed.
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?
With 0% schema description coverage and 7 parameters, the description fails to explain most parameters. It only mentions time range behavior (startTime, endTime default) but ignores transferId, coin, status, limit, cursor. This requires the agent to infer from names, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries universal transfer records and explains the scope for master and sub API keys. The verb 'Query' and resource 'universal transfer records' are specific. It distinguishes itself from sibling tools like interTransferListQuery by its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool with master vs sub API keys and includes time range rules. However, it does not mention alternative tools or when not to use it, though the context implies uniqueness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that only unfilled/partially filled orders can be amended, response is asynchronous, and price='' keeps existing price while price='0' sets to zero. However, it omits details about permissions, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with usage scenarios and important notes. It is concise but contains a redundant 'Agent hint:' section that repeats earlier points. Overall, it is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key usage scenarios and constraints but lacks explanation of return values (no output schema) and error conditions. The asynchronous response is noted, but more detail on order lifecycle or edge cases would improve 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?
Schema coverage is 0%, so the description must add meaning. It explains behavior for 'price' and 'qty', and notes orderId/orderLinkId usage. However, it incorrectly implies orderId/orderLinkId are required (schema shows only 'symbol' as required), creating a contradiction. The required 'symbol' parameter is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool amends price and/or quantity of an existing spread trading order. It uses a specific verb ('Amend') and resource ('spread trading order'), distinguishing it from sibling tools like 'amendOrder' (for regular orders) and 'createSpreadOrder'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage scenarios: adjusting price without cancellation, modifying quantity of unfilled/partially filled orders. It specifies which parameters are needed (orderId/orderLinkId) and notes that only unfilled/partially filled orders are modifiable. However, it does not explicitly contrast with alternative tools like 'amendOrder' for non-spread orders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the quote lifecycle (30-second expiry), the return values, and the Master UID restriction. It does not mention whether the tool mutates state, but the information given is detailed and helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points for return values, rules, important notes, and use cases. It is concise and front-loaded with the purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of parameter descriptions and no output schema, the description covers the overall behavior and constraints well, but leaves gaps in parameter semantics. An agent would need more details to invoke the tool correctly without additional context.
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%, and the description does not explain individual parameters. It mentions 'fromCoin', 'toCoin', and 'requestAmount' implicitly but does not clarify 'fromCoinType', 'toCoinType', or 'requestCoinType' (default, enum values). For 6 parameters, this is insufficient.
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 applies for a conversion quote and lists the returned data. It uses specific verbs and resources, but does not explicitly differentiate from siblings like 'createQuote' or 'QuoteApply', which limits clarity slightly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides use cases (lock in rate, show exact amount, validate trade parameters) and important notes (Master UID only). It does not explicitly state when not to use the tool or mention alternatives, but the context is sufficient for basic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the core behavior (confirms MMR, removes reduce-only) and the triggering condition. However, it does not mention potential side effects, idempotency, error scenarios, or what happens if called without a pending update, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the key action, followed by a concise agent hint. Every sentence adds value with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain the return value or success indication, which it does not. It also lacks parameter details and error handling info. However, it does provide good usage context via the agent hint and references getPositionInfo, partially compensating.
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% and the description does not explain the parameters (category, symbol). While the parameter names are somewhat self-explanatory, the description adds no additional meaning or guidance on what values to use, such as clarifying that symbol likely refers to the trading pair.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool confirms a pending maintenance margin rate update and removes the reduce-only restriction. It specifies the exact context (Bybit risk limit adjustment) and distinguishes its purpose from sibling tools by being the only confirmation action of this kind.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'Agent hint' that tells the agent when to use this tool (when isReduceOnly=true due to risk limit adjustment) and advises checking getPositionInfo first. It does not explicitly state when not to use it, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It only states it queries without disclosing side effects, authentication needs, rate limits, or error behavior. It is a simple read, but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with purpose, followed by parameter details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter (1) and no output schema, the description covers the input format but lacks details about output structure, possible errors, or behavior on invalid input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning: 'accepts one or more coin names separated by commas (max 20 coins)'. This compensates for the minimal schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Query' and resource 'available withdrawal balance for specified coin(s) in the Unified account', clearly distinguishing it from sibling tools like 'getWithdrawableAmountByCoin' which may have different scope. The purpose is unmistakable.
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 states that coinName is required and accepts multiple coins (max 20), which is useful but does not explicitly compare with similar tools (e.g., getWithdrawableAmountByCoin) or provide when-to-use/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the endpoint returns a ranked list and that order should be preserved, but fails to disclose read-only nature, rate limits, auth requirements, or any side effects. The behavioral transparency 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose, but the agent hint is a lengthy, undivided paragraph containing detailed conversational flow instructions that could be more concise or structured separately. It earns its place but could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description is fairly complete. It explains the output (ranked list of providers, metrics like 30-day return) and provides a full use case with sibling tool integration, making it actionable for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (0 params). Per the rubric, baseline is 4 since no parameter information is needed. The description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get a curated Copy Trading TradFi leaderboard for conversational recommendation flows,' clearly stating the verb and resource. It distinguishes from the sibling `getCopyTradingClassicLeaderboard` later in the agent hint, though not in the opening sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The agent hint explicitly states when to use this tool ('If a user asks for a reliable copy trader'), instructs to call both Classic and TradFi leaderboards, and provides detailed steps for presenting and comparing lists. This is exemplary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does this well by documenting eligibility restrictions, the exact inventory formula (min(market available + financial trial, user remaining borrow limit)), precision/rounding behavior, and the rate requirement. Minor gaps remain around response shape and error behavior, but the core calculation is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized: a single scoping sentence followed by focused bullet-point rules. Each bullet adds distinct information, and there is no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers eligibility, the inventory formula, precision, and rate constraints, which is substantial for a query tool. However, with no output schema and no annotations, it omits the response format and the exact accepted values for 'term' and 'annualRate'. These are meaningful gaps for an agent constructing a request and interpreting the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 0%, so the description must compensate. It clarifies that 'currency' is a coin name that must be uppercase and supported, and that 'annualRate' is the request rate used in the rate check. However, it never explains the accepted format for 'term' or the numeric representation of 'annualRate', leaving important call-construction details unspecified.
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 opening sentence states a clear action and target: 'Query available lending pool inventory for fixed-term loan.' This distinguishes it from flexible-loan inventory siblings at a high level, but the description does not differentiate it from the near-identical sibling 'queryFixedAvailableInventory'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the description: use this to query fixed-term loan available inventory. It also provides domain constraints such as supported coins and uppercase coin names, but it never explicitly says when to choose this tool over alternatives like 'queryFixedAvailableInventory' or 'getCryptoLoanFlexibleAvailableInventory'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It communicates the operation is a read-style retrieval ('Returns'), scopes data to the authenticated user, explains pagination, and discloses the hard constraint that startTime and endTime must be provided together as 13-digit ms timestamps. It does not mention rate limits or response shape, but the core behavioral traits are covered.
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 front-loaded with the core purpose, but it contains redundancy: the 'AI agent can use this' paragraph and the 'Agent hint' paragraph both restate that the endpoint retrieves staking operation history, and 'Filter by type' repeats the earlier filtering statement. Tighter editing would improve it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for basic invocation: it explains the operation type codes, the timestamp pairing requirement, and pagination intent. But with no output schema and no annotations, it does not describe the response structure, explain the status parameter values, or clarify how this endpoint differs from getLaunchpoolUserHistory. These gaps reduce completeness for an agent deciding whether and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaningful semantics for type (0=pledges, 1=manual redemptions, 2=interest credits) and for startTime/endTime format and pairing. However, status values are not explained, and coin/stakeCoin semantics are only implied by 'Filter by coin', leaving gaps for a 7-parameter tool.
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 returns the authenticated user's Launchpool staking operation history with pagination and filtering options. It identifies the resource and action specifically, though it does not explicitly distinguish itself from the similarly named sibling getLaunchpoolUserHistory, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases: showing a user their staking history or investigating operation types like pledges and redemptions. It also gives practical filtering guidance, but it does not state when to prefer this tool over getLaunchpoolUserHistory or getLaunchpoolUserCurrentStaking, so exclusions and alternatives are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions batch queries but omits rate limits, error behavior, authentication needs, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, no redundancy, front-loaded with core purpose and batch capability.
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?
Covers basic purpose and batch usage but lacks details on optional parameter, response structure, and error cases. Without output schema, more completeness would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning to tokenCode by explaining batch array usage. ChainCode parameter is not mentioned in description. With 0% schema coverage, partial compensation is borderline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Query current USD prices for one or more payment tokens' with a specific verb and resource, and distinguishes from siblings by specifying LP pay tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases ('calculate USD value of stake amounts', 'show price info to users') and an agent hint. Lacks explicit when-not-to-use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It implies a read-only query by stating 'Query available payment tokens' and describing the response, but does not explicitly declare it non-destructive or explain authorizations, rate limits, or error behavior. Still, the read intent is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is repetitive, restating the same advice ('Do NOT use...', 'Agent hint:...') multiple times. It could be cut by half without losing information. Every sentence does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately explains the tool's role in the trading workflow and when to call it, but falls short on parameter details and return format (no output schema). For a simple query tool with two parameters, it covers the conceptual context but fails to enable correct 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?
Schema coverage is 0% with no parameter descriptions. The description does not mention chainCode or tokenAddress at all, so the agent gets no guidance on how to populate these required parameters. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries available payment tokens for trading, and specifies the return fields (token symbol, CEX code, limit, blockchains). It also distinguishes itself from getBizTokenList and getBizTokenPriceList, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: call before trading to resolve user input to CEX token codes, required before getTradeQuote. Also tells the agent when NOT to use it (for on-chain tokens or prices) and points to specific alternative tools, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the transparency burden. It indicates a read-only query and mentions the maximum tokenIds count, but lacks details on rate limits, response size, or potential errors if limits are exceeded.
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 reasonably front-loaded but contains repetition of 'Maximum 20 tokenIds per request' (appears twice). Could be more concise without losing 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?
With no output schema, the description should at least outline the return structure—it only says 'all price levels with available quantity'. Missing explanation of tokenIds and response format leads to incomplete context.
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 coverage is 0%, so the description must explain tokenIds. While it mentions 'specific tokenIds' and the max count, it doesn't define what tokenIds are (e.g., outcome token identifiers) or how to obtain them.
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 tool name and description clearly state it queries the full order book (bid/ask depth) for prediction outcome tokens. It distinguishes itself from the sibling tool getPredictionTokenPrice by specifying it returns all price levels versus just the best price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (to estimate price impact, display market depth) and when not to (for best price, use getPredictionTokenPrice). It also includes a practical constraint: maximum 20 tokenIds per request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states it's a query, but lacks details on side effects, authentication needs, rate limits, or response format. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the purpose and adding a constraint. Every word earns its place; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description adequately conveys the tool's function and a usage constraint. However, it lacks any mention of return values or potential errors, making it somewhat incomplete for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. Per the rubric, 0 parameters baseline is 4. The description adds no parameter info because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Query' and the resource 'Spot margin status and leverage', specifying the scope 'unified account'. Among siblings like getSpotMarginTradeCoinState, this tool is distinct as it returns the overall state, so purpose is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a context hint ('Unified account only') but does not explicitly state when to use this tool versus alternatives like getSpotBorrowQuota or getSpotMarginTradeCoinState. Some guidance on usage context is implied but not fully developed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It states authentication requirements, confirms there are no query parameters, and says it returns current configuration. 'Query' implies read-only, but it does not explicitly declare the absence of side effects or discuss error/rate-limit behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-structured: a front-loaded lead sentence about the capability, followed by two focused bullet notes. Every sentence contributes useful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter query tool with no output schema, the description provides the essential invocation context: authentication required, no query parameters, and the returned data is the authenticated user's account settings. It does not enumerate all response fields, but that is acceptable given the simplicity and absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has zero parameters, so nothing extra is required. The description adds explicit confirmation that there are no query parameters, matching the schema exactly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query') and names a distinct resource ('user account setting configuration'), while listing example contents such as margin mode, account mode, and spot hedging status. It is clear about what the tool does, though it does not explicitly differentiate itself from nearby read tools like getAccountInfo.
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 conveys the basic context: it requires authentication, takes no query parameters, and returns the current account configuration for the authenticated user. However, it does not explicitly state when to choose this tool over alternatives or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that results are sorted descending by creation time and limited to 100 records per page. This is adequate for a read-only query, but it omits details about authentication requirements, potential rate limits, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate sections for the main purpose, query parameters, and use cases. It is concise, with no extraneous sentences, and front-loads the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers usage, parameters, sorting, and max records, it does not specify the return structure of the historical trade records. Given no output schema, this omission leaves the agent unclear about what fields to expect, making it less complete for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions time range filtering, pagination, and max 100 records, which maps to startTime, endTime, limit, and index. However, it does not explain the format for time strings, the behavior of the index parameter (e.g., offset-based), or the exact relationship between parameters. This adds some meaning beyond the bare schema but lacks full clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries historical trade records with pagination, time range filtering, and sorting. It distinguishes itself from many sibling tools (e.g., getTradeHistory, getOrderHistory) by explicitly mentioning 'historical trade records' and pagination features.
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 lists three specific use cases (trade reports, reconciliation, export for accounting) which imply when to use this tool. However, it does not provide explicit guidance on when not to use it or mention alternative tools for similar tasks, lacking exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behaviors: parameter interactions (addressType ignoring coin/chain), filtering of failed verification, security policy effects on new address status, and the use of baseCoin for universal addresses. However, it omits behavior for addressType 0 and pagination details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-line purpose followed by bullet-pointed business rules. It is front-loaded and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description covers main behaviors and parameter interactions but lacks details on output format or pagination. It is adequate but not fully complete for an agent to use without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds meaning for addressType, coin, and chain (e.g., ignoring coin/chain for certain addressTypes, using baseCoin). But it does not explain limit and cursor parameters, leaving them undocumented.
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 'Retrieve withdrawal addresses from the address book,' identifying the specific action and resource. It distinguishes this tool from sibling tools like queryWithdrawRecords (which retrieves withdrawal history) and queryDepositAddress (deposit addresses).
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 mentions a prerequisite (API key must have withdrawal permissions) but provides no explicit guidance on when to use this tool versus alternatives like queryWithdrawRecords. The agent must infer usage context from the name and purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially discloses behavioral traits: early redemption results in discounted APY or zero earnings, and positions within a redemption window cannot be redeemed. It mentions the rate limit. However, it does not clarify the actual mutation (position closure/reduction) or output behavior, leaving gaps for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus bullet points covering key conditions and rate limit. It front-loads the main action. There is minimal redundancy, though the bullet points could be better integrated. Overall, efficient use of space.
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 three parameters, no output schema, and no annotations, the description provides useful context on eligibility and rate limits but lacks details on return values, error scenarios, and prerequisites. It is adequate for basic understanding but not fully complete for an agent to predict outcomes.
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 three parameters (productId, category, positionId) with no description in the schema. The tool description does not explicitly explain each parameter; it only indirectly relates category to product types mentioned in the notes. This is insufficient for an agent to understand parameter values without additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for 'early redemption for a fixed term position', which is a specific action on a specific resource. It differentiates from siblings like placeFixedTermOrder (creation) and getFixedTermPosition (query) by focusing on redemption. The notes further clarify product-specific behavior, reinforcing purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool: for early redemption of fixed term positions, with conditions for different product categories (FundPool with allowEarlyRedemption=true, FixedTermSaving if allowed) and a restriction for positions within redemptionLimitDuration. It does not explicitly mention alternative tools or when not to use, but the eligibility criteria are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Discloses mode behavior, equal size constraint, cancellation method, and positionIdx meaning. Missing side effects (immediate? reversible?), permission requirements, or error handling. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences efficiently convey purpose and key rules. Starts with general purpose, then agent hint with parameters. Could be slightly better structured (e.g., separate parameter descriptions), but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite complexity (16 params, no output schema, no annotations), description covers only a fraction of parameter semantics and lacks expected behavior, output, and error conditions. Many required fields (category, symbol) are not explained. Significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. Adds meaning for tpslMode (Full/Partial), tpSize/slSize equality, cancellation via '0', positionIdx values. However, 12 other parameters (category, symbol, takeProfit, etc.) are undocumented, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool configures trading stop parameters (TP, SL, trailing stop) on open positions. Uses specific verb 'configure' and resource 'trading stop parameters'. Distinguishes itself from sibling order tools by focusing solely on stop settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit agent hint on usage: use for setting TP/SL/trailing stop, explains Full vs Partial mode, requirement for equal sizes in Partial, cancellation via '0', and required positionIdx. Lacks explicit when-not-to-use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It mentions that this creates a real loan with interest obligations, depends on available supply, and is for Unified account only. However, it does not explain side effects (e.g., what happens on insufficient supply), authorization needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points for rules and a separate agent hint. It is concise but includes necessary details. Every sentence adds value, though a bit more brevity could be achieved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description provides basic context like account type and dependencies but lacks information on return values, error handling, and prerequisites like collateral requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 0%, so the description is expected to explain parameters. It partly does: it explains the 'term' (enum values), 'strategyType' (PARTIAL/FULL), and 'repayType' (1/2). But it does not explain 'orderCurrency', 'orderAmount', or 'annualRate', leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'fixed-rate borrow order for Unified account'. It includes specific rules and constraints (e.g., supported terms, strategy types) that distinguish it from other tools. The title itself is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit rules for when to use the tool (e.g., fixed terms, order strategy, maturity handling) and an agent hint that requires user confirmation before execution, indicating when not to proceed automatically. However, it does not explicitly compare this tool to other borrow-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behavioral traits: async nature, authentication (API key), ACL permissions, rate limits, and KYC requirement. This provides good transparency, though it omits idempotency or error handling details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It uses a clear lead sentence followed by bullet points for authentication, permissions, rate limits, and KYC. No extraneous 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 simple input (1 parameter) and lack of output schema, the description covers authentication, rate limits, and async behavior. However, it does not explain the return value format, potential error states, or the expected behavior of the async operation (e.g., polling interval).
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 sole parameter 'quoteTxId' has no schema description (0% coverage). The description adds minimal context by stating it's a 'quote ID' for conversion, but does not specify format, source, or examples. For a critical parameter, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'confirm and execute a conversion based on quote ID,' specifying the verb (confirm and execute), the resource (conversion), and the input (quote ID). It distinguishes from sibling tools like 'confirmQuote' and 'executeQuote' by combining both actions and mentioning async behavior.
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 after confirming a quote ('Make sure you confirm the quote before it expires'), but it does not explicitly state when to use this tool versus alternatives like 'executeQuote' or 'applyQuote'. The guidance on async and checking status via query result API is helpful but lacks explicit differentiation from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does state a rate limit (50 req/s), which is helpful for operational awareness. However, it does not explicitly confirm read-only behavior, idempotency, error responses, or side effects. The information is partially transparent but incomplete.
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 two sentences: one for tool purpose (listing returned fields) and one for rate limit. Every word serves a purpose; no redundancy or fluff. This is an excellent example of efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only one parameter and no output schema, the description adequately covers the returned information (coin, denomination, etc.). It could mention potential errors or the nature of the voucher ID, but for a simple read operation, the context is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It implies the `id` parameter identifies the voucher but does not specify format, constraints, or examples. While the single parameter's role is clear from context, the description adds minimal value beyond what the schema name suggests.
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 uses the verb 'Get' and specifies the resource as 'basic information of a specified voucher', listing concrete fields (coin, denomination unit, product line, total amount, distributed amount). This differentiates it from the sibling tool 'distributeAward', which implies creation/distribution, making the purpose distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., other info retrieval tools). It simply states what it does, leaving the agent to infer usage context. No when-to-use or when-not-to-use conditions are given, which is acceptable but lacks depth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It discloses that the tool is a read-only validation (no side effects), returns allowable ranges and a check_code, includes a rate limit of 10 requests per second, and explains the behavior on validation failure (check_code non-zero). This is sufficient for an agent to understand its behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise, front-loading purpose and usage. It has a clear structure: purpose, usage instruction, rate limit, and agent hint. Every sentence adds value, though it could be slightly tighter by removing redundant phrases.
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 (11 parameters, no output schema, no annotations), the description is incomplete. It does not explain the symbol_settings array, the enum values for adjust_position_mode, or the boolean need_to_slippage. The output is only partially described (ranges for some parameters, check_code). An agent would need more information to use this tool effectively.
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 11 parameters with 0% description coverage. The description mentions some parameters (initial margin, leverage, rebalancing threshold, time interval, TP/SL percentages, trailing stop) but fails to explain others like adjust_position_mode (an enum with unexplained values), symbol_settings (a complex array), need_to_slippage (boolean), and app_name. This leaves significant gaps for the agent.
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 that the tool validates input parameters for creating a futures combo bot and returns allowable ranges. It uses specific verbs ('validates', 'returns') and identifies the resource ('input parameters for creating a futures combo bot'). This distinguishes it from sibling tools like createComboBot (which creates) and getComboDetail (which retrieves details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to use this endpoint before calling /v5/fcombobot/create to ensure parameters are within valid bounds. It also includes an 'Agent hint' reinforcing this. While it doesn't explicitly mention when not to use it, the guidance is clear and appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool exposes PII if misused, which is a critical behavioral trait. However, it does not mention whether the operation is read-only or any other side effects, but the nature of 'get' implies read-only.
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 only two sentences plus a hint, all front-loaded with the purpose. No unnecessary words or details, making it easy to read 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 no annotations, no output schema, and 0% parameter documentation, the description is incomplete. It fails to specify what information is returned about the counterparty user, how to use the parameters correctly, and does not differentiate from similar tools beyond the hint.
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 two parameters (originalUid, orderId) with no descriptions and 0% schema coverage. The description only mentions 'specific order' and 'counterparty', leaving the role of originalUid ambiguous. The description does not clarify which parameter corresponds to what.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets information about a counterparty user in a specific order, which is a specific verb and resource. It distinguishes from siblings like getAccountInfo or getAffiliateUserInfo by focusing on counterparty and order context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Agent hint' explicitly tells the agent to only query the counterparty of the current active order and not to enumerate UIDs or call in a loop, with the reason that it exposes PII of unrelated users. This is excellent usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses that the endpoint is public (no auth required), supports querying by specific currency or all, and has a rate limit of 1000 requests per time window. It does not mention any destructive behavior, which is appropriate for a read-only query. This goes beyond just stating the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a header, bullet-point features, and a list of use cases. It is concise, covering all necessary information without unnecessary fluff. Could be slightly more streamlined, but generally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter and no output schema, the description covers purpose, features, use cases, rate limits, and authentication. It explains what the tool returns conceptually (liquidation order, tiered ratios) but does not detail the response format, which might be acceptable if the API is well-known. Overall, it provides enough context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter 'currency' with 0% description coverage. The description adds meaning by explaining that omitting the parameter returns all collateral currencies, while providing a specific currency filters the result. This compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries information about currencies available as collateral. It lists features like querying by specific currency or all, liquidation order, tiered ratios. However, it does not explicitly differentiate from sibling tools like getCryptoLoanCommonLoanableData or getTieredCollateralRatio, which could be similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides use cases indicating when to use the tool (check collateral eligibility, view liquidation priority, etc.). It includes rate limit info and authentication status. However, it does not mention when not to use this tool or suggest alternative tools for specific needs, like if a user needs more detailed ratio data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions features like querying by repayment ID or currency, pagination support, and viewing details including principal and interest. It also notes a rate limit. However, it does not specify pagination mechanics (e.g., cursor usage), whether results are ordered, or if both completed and pending repayments are included. This leaves gaps 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and sections (Features, Use Cases). It is appropriately sized and front-loaded with the core purpose. While clear, some sentences (e.g., 'Rate limit: 5 requests per UID') could be integrated more succinctly. Overall, it earns its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should provide more detail on return values. It mentions 'repayment details including principal and interest' but does not describe the full response structure, pagination metadata, or behavior for empty results. With 4 parameters (0 required) and moderate complexity, the description is somewhat complete but leaves users guessing about the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 4 parameters with 0% schema description coverage. The description adds basic semantics: 'Query by repayment ID or currency' maps to repayId and loanCurrency, and 'Pagination support' maps to limit and cursor. However, it does not clarify that no parameters are required, nor does it explain parameter formats or allowed values. The added value is limited.
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 'Query historical flexible repayment records with pagination,' specifying the verb (Query) and resource (flexible repayment records). It distinguishes itself from sibling tools like getCryptoLoanFlexibleBorrowHistory and getCryptoLoanFixedRepaymentHistory, which target different aspects of crypto loans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists explicit use cases: 'Track repayment history, Verify repayment transactions, Calculate total interest paid.' It also mentions a rate limit as a usage constraint. However, it does not provide guidance on when not to use this tool or compare it to similar tools (e.g., fixed repayment history), leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that no authentication is required and rate limit is 50 req/s. As a 'Query' tool, it implies read-only behavior, but does not explicitly state non-destructiveness. The provided info adds valuable behavioral context beyond a basic description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and a rate limit note. It is front-loaded with the core purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description covers the main operation but omits crucial parameter semantics. An agent would lack guidance on how to specify the coin. Without explaining the parameter, the description is incomplete for practical 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 a single parameter 'coin' with no description (0% coverage). The description fails to mention this parameter at all, leaving it unclear what values are valid or if it is required. Given the low coverage, the description should compensate by explaining the parameter's role, but it does not.
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 'Query fixed term product information' with concrete examples like tiered APY, min/max stake amount, product status. This specific verb+resource combination distinguishes it from sibling tools such as getFixedTermOrder or placeFixedTermOrder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides authentication and rate limit info, which is helpful for usage. However, it does not explicitly state when to use this tool over alternatives (e.g., getFixedTermPosition) or when not to use it. The usage context is implied but not formalized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description covers behavioral aspects well: it explains return types (SPOT, CONTRACT, etc.), filtering logic, and account type combinations for UTA/UMA/Classic accounts. It does not mention rate limits or authentication details but is largely transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and bullet points, providing detailed information without being unnecessarily verbose. The first sentence is a clear summary, and subsequent sections add depth efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description effectively explains return values and account type combinations. It covers filtering rules and usage notes, making it complete for a read-only tool with one parameter.
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 only parameter 'memberIds' has 0% schema description coverage, and the description does not clarify the expected format (e.g., comma-separated, JSON array). It only says 'specified member IDs', which adds minimal value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves account type information for specified member IDs, using active verbs like 'Get' and 'query'. It distinguishes itself from sibling tools by focusing on account type details.
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 mentions using master or sub-account API keys and includes filtering rules, but does not explicitly specify when to use this tool over alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists key return fields (e.g., mmpEnabled, window, frozenPeriod) and explicitly states the rate limit (5 req/s), adding value beyond the input schema. It implies read-only behavior but does not explicitly confirm idempotency.
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 efficient with five sentences, front-loads the purpose, and includes a rate limit and agent hint without fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description covers purpose, key return fields, and usage hint. It helps an agent understand the response structure, but lacks explicit read-only confirmation and parameter details.
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 description only states that baseCoin is required, which duplicates schema information. With 0% schema coverage, it fails to explain the parameter's meaning (e.g., currency code like BTC) or expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries 'Market Maker Protection configuration and freeze status' for a specified base coin, distinguishing it from sibling tools like setMmp or resetMmp which handle mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an agent hint to 'check MMP settings and freeze status,' implying a read-only usage intent, but lacks explicit guidance on when to use this tool versus alternatives (e.g., setMmp for modification).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the data is public, anonymized, requires authentication, has a 30-day time window constraint, a rate limit of 50 req/s, and supports pagination. It does not mention response structure or data freshness, but overall it's highly transparent for a read query.
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 relatively concise with two paragraphs plus a rate limit line and agent hint. The first sentence captures the core purpose. However, it repeats the time window constraint twice, which is slightly wasteful. Well-structured overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and zero parameter descriptions, the description covers the tool's purpose, constraints, and usage hints. But it omits crucial details like whether startTime/endTime are optional, the exact format of parameters, and the response structure. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the time window constraint and pagination but does not specify parameter formats (e.g., startTime as Unix timestamp) or the cursor string. Adds some context but insufficient for a 4-parameter tool with no schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries publicly available RFQ trade data with optional time range and cursor-based pagination. It distinguishes itself from siblings like getRecentPublicTrades which is for recent trades without filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides hints about authentication and time window constraints but does not explicitly guide when to use this tool versus alternatives like getRecentPublicTrades or getTradeHistory. Usage is implied but not clearly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: authentication requirements, exclusion of sub-accounts, and error conditions for banned/custody/UAE users. It does not describe the return format, but the query nature implies the address is returned.
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 efficient: one concise sentence followed by four informative bullet points. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of parameter documentation and output schema, the description is adequate but not complete. It covers purpose and constraints well but misses parameter semantics, which is a notable gap for a 2-parameter tool.
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 coverage is 0% and the description adds no explanation for the 'coin' or 'chainType' parameters. While 'coin' is somewhat inferred, 'chainType' is not defined at all, leaving the agent unclear about possible values or optionality implications.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool queries deposit address information for the master account. It specifies the resource and action ('Query the deposit address information') and distinguishes from sibling 'querySubMemberDepositAddress' by explicitly targeting the master account, not sub-accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit constraints on who can call (main UID API key) and who cannot (sub-accounts, banned/custody/UAE-restricted users). While it does not name an alternative tool, the sibling list includes 'querySubMemberDepositAddress' for sub-accounts, making the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses destructive default (clear buffer), limit capability, and return status field. However, no annotations provided, and description lacks rate limits, error handling, or prerequisites for subscription.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with front-loaded action, clear structure using semicolons for details, no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, description covers key behaviors, parameter effects, and return field. Missing details on invalid subscription or empty buffer, but contextually sufficient given sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description reinforces parameter purposes (limit for recent N, clearAfterRead for buffer clearing) but adds no new constraints or formats beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb '读取' (read) and resource '指定订阅已积累的消息' (accumulated messages of specified subscription), distinguishing it from sibling tools like startSubscription, stopSubscription, and listSubscriptions.
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 explains default behavior (clearAfterRead=true) and alternative (clearAfterRead=false) but does not explicitly contrast with streaming subscription tools (e.g., subscribe_*) or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It includes a rate limit (20 rps) which adds transparency. However, it does not explicitly state that the tool is read-only (no side effects). The behavioral info is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is 8 sentences, front-loaded with purpose, then rate limit, then agent hint. No wasted words. Slightly verbose in the rate limit formatting, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description lacks completeness. It does not specify the structure of the returned strategy or enumerate possible biz values. The agent would need external knowledge to fully interpret the response for downstream create endpoints.
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 coverage is 0%, so description must explain parameters. It mentions symbol, product, and direction as a triple but does not decode enum values (e.g., product '0' vs '1'). This leaves the agent without full understanding of parameter ranges. Some high-level meaning is provided but insufficient for precise invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns a recommended strategy and bot business type for a given triple, explicitly distinguishing its role in the EasyBot one-click create flow. The agent hint reinforces when to use it versus alternatives, making purpose very specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit agent hint says 'Use this when the user wants the simplest path to create a bot', providing clear when-to-use guidance. It also describes the input and output flow, and implies not to use when more complex configuration is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the tool sets maximum leverage (mutation) and includes a prerequisite and range. However, it omits potential side effects, permissions, or rate limits, which are common for mutation tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, with no fluff. The first states the purpose, the second adds conditions, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return values, but does not. The currency parameter is also unexplained. However, the tool is simple and the description covers core usage, so it is partially complete.
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 schema has 2 parameters with 0% description coverage. The description adds meaning to 'leverage' by specifying a valid range (2-10), but does not explain the 'currency' parameter at all, leaving it ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets maximum leverage for spot cross margin trading, specifying the action, context, and prerequisite. It distinguishes from siblings like 'setLeverage' by focusing on spot cross margin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite (spot margin activated) and valid leverage range (2-10), providing clear context. It does not explicitly state when not to use or compare to alternatives, but the given information is sufficient for basic usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses persistence, message accumulation, auto-close after 5 minutes, and support for multiple independent subscriptions. Additional details like authentication needs or reconnection behavior are omitted.
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?
Three concise sentences, front-loaded with the main action, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers the tool's purpose, lifecycle, and relation to other tools. Lacks details on error handling or output format, but given no output schema, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 covers all 4 parameters with descriptions. Description adds behavioral context (e.g., maxMessages buffer limit) but does not significantly enhance parameter meaning beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it starts a persistent WebSocket subscription and returns a subscriptionId. It distinguishes from sibling tools like readMessages and stopSubscription by explaining the lifecycle, but does not explicitly differentiate from many subscribe* sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage pattern (start, read, stop) and mentions auto-close timeout, but does not provide explicit when-to-use or when-not-to-use guidance compared to alternative subscription methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It reveals the rate limit (50 req/s) and caller restriction (RFQ creator). However, it does not describe side effects, reversibility, or state changes the RFQ undergoes, which are important for an 'accept' operation. Adequate but has gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a clear main sentence, a clarifying sentence, a rate limit, and a structured agent hint. Every sentence adds value without redundancy. Well-organized for quick comprehension.
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 only one parameter and no output schema, the description lacks information about the return value or success criteria. It implies the action is taken but doesn't confirm what happens after calling. May be sufficient for a simple toggle, but missing outcome details.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 0%, so the description must compensate. It adds that 'rfqId' is the ID of the target RFQ, which is helpful but minimal. No format, source, or example is provided. For a single required parameter, this is adequate but not excellent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enables acceptance of non-LP quotes for a specific RFQ, distinguishing it from other quote-related sibling tools like applyQuote, createQuote, or confirmQuote. The verb 'accept' and resource 'non-LP quotes for a specific RFQ' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The agent hint explicitly says to use this endpoint to allow non-LP counterparties to quote on your RFQ, and notes that only the RFQ creator can call it. This provides clear use context and an important precondition. It does not list explicit alternatives or when not to use, but the hint is sufficient for its purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the action adds real collateral, includes a rate limit (5 req/s), and warns of automatic execution risks via the agent hint. It does not detail failure modes or reversibility but is sufficiently transparent 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose, then rate limit and agent hint. It is front-loaded with the core action. Slightly better formatting (e.g., bullets) could improve readability, but the content is 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?
No annotations or output schema are provided. The description covers purpose, user confirmation requirement, and rate limit but omits parameter details and result behavior. It is adequate but incomplete for a 5-parameter required tool.
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 coverage is 0% with 5 required parameters. The description only hints at positionId and amount via the agent hint, leaving productId, orderLinkId, and quoteAccountType unexplained. Given low coverage, more parameter context is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds collateral to a leveraged Liquidity Mining position to avoid liquidation. It specifies the verb 'add', the resource 'collateral/margin', and the purpose, distinguishing it from siblings like addLiquidity or addReduceMargin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clarifies when to use the tool (to avoid liquidation on leveraged positions) and includes an agent hint requiring user confirmation. However, it does not explicitly state when not to use it or provide alternatives, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that response is acknowledgment only, the order must be open, and updates can include price, qty, TP/SL, and orderIv for options. However, it does not reveal side effects, authentication needs, rate limits, or what happens on failure.
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 short, front-loads the main purpose, and uses bullet points effectively. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 16 parameters and no output schema, the description covers core behavior and constraints but is incomplete on parameter details and return value. It also lacks error handling context, which is important for a modification tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains 9 out of 16 parameters (category, orderId, orderLinkId, price, qty, triggerPrice, takeProfit, stopLoss, orderIv) and gives usage tips for options and TradFi. But 7 parameters remain unexplained, including tpslMode, triggerBy, and limit prices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'modify' and resource 'existing open order', lists the updatable parameters (price, quantity, trigger price, TP/SL), and distinguishes from sibling tools like createOrder 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear conditions for use: must provide orderId or orderLinkId, only unfilled/partially filled orders, and category hints for TradFi. Also acknowledges response is merely acknowledgment and advises confirmation via WebSocket. However, does not explicitly compare with batchAmendOrders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the tool is for order placement (mutation), imposes max limits, supports partial success, and provides only acknowledgment (not confirmation), directing users to confirm via WebSocket. This is fairly transparent for a batch mutation tool, though it omits authentication or rate limit details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points for key behavioral traits, followed by an agent hint and TradFi note. It is concise, front-loads the purpose, and every sentence adds value. There is no unnecessary repetition or fluff.
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?
No output schema is provided, so the description should clarify the response format. It mentions that the response is an acknowledgment and that per-order status is in 'retExtInfo.list[].code', which gives a partial picture. However, it does not describe other possible response fields, error handling, or pagination. Given the tool's complexity (batch with many parameters), this is a notable gap, but the description covers the essential usage points.
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 schema coverage is 0%, so the description must compensate. It adds value for the 'category' parameter by explaining the TradFi mapping (spot for xStock, linear for equities/commodities). However, it does not explain the many fields inside the 'request' array (e.g., symbol, side, orderType). The description's mention of 'per-order status' is helpful but insufficient to cover the parameter richness. A more thorough parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Place multiple orders in a single API call.' It specifies the verb (place), the resource (multiple orders), and distinguishes it from single-order creation (createOrder) by emphasizing batching. The limits and partial success details further clarify its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when placing multiple orders simultaneously. It includes practical constraints (max 20 for futures/options, 10 for spot) and instructions on interpreting partial success. It does not explicitly state when not to use it, but the agent hint and TradFi mapping help guide usage. The exclusion of alternatives is implied by the tool's specific batch nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses the bot's behavior (manages portfolio, rebalances), rate limits (10 req/s/UID), compliance requirements (GEO IP, KYC), and the need for bot_id in later steps. It does not explicitly state whether creation is irreversible, but the information provided is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficient. It front-loads the core purpose, then provides prerequisites, rate limits, and an agent hint in a logical order. Every sentence adds value without redundancy, and the length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, no output schema, no annotations), the description covers essential usage and prerequisites but fails to explain response structure beyond bot_id, many optional parameters, and error handling. It is adequate for experienced users but incomplete for full autonomous agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains required parameters (leverage, init_margin, adjust_position_mode, symbol_settings with at least one entry having symbol, target_position_percent, side) but does not describe optional parameters like adjust_position_percent, sl_percent, tp_percent, or trailing_stop_percent. Partial coverage leaves many parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates a futures combo trading bot that manages a portfolio of multiple futures symbols and automatically rebalances positions. It distinguishes from sibling bot creation tools by specifying 'futures combo' and mentioning rebalancing modes, though it does not explicitly compare to alternatives like DCABot or GridBot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidelines: calling getComboLimit first to validate parameters, requiring at least one symbol_settings entry with specific fields, and noting that the bot_id is needed for subsequent operations. It also mentions rate limits and compliance checks but does not specify when to avoid using this tool or recommend alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses rate limit (3 qps per UID), error behavior (status_code 421 with ban_reason_text), and specifies return value (grid_id). It also mentions optional features like trailing stop and grid trailing. Missing details on idempotency or side effects, but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear main sentence, followed by optional features, prerequisites, response, rate limit, and agent hints. It is front-loaded and concise, though some details (like invest_mode explanation) could be integrated more neatly. Generally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (20 parameters, no output schema, no annotations), the description provides a reasonable overview of functionality, prerequisites, and error handling. However, it lacks detailed descriptions for numerous parameters and does not cover all possible error scenarios or side effects, leaving gaps for an AI agent to fully understand the tool's capabilities.
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 explains some parameters (symbol, price range, grid count, investment amount, invest_mode) but fails to describe many others (e.g., cell_number, followed_grid_id, source, block_source, create_type, ts_percent, enable_trailing). With 20 parameters and minimal explanation, the description insufficiently adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a spot grid bot with the specified trading pair, price range, grid count, and investment amount,' providing a specific verb and resource. It distinguishes from siblings like validateGridInput and closeGridBot by describing the creation action and required parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly includes prerequisites: 'Call validateGridInput first' and 'User must be authenticated and pass KYC/compliance checks.' It also gives an agent hint to always call validateGridInput before this endpoint. However, it does not specify when not to use this tool or list alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses rate limit (50 req/s) and constraint that all legs share same base/settlement coins. With no annotations, description carries burden; missing details on authorization, idempotency, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and bold labels. Every sentence adds value; no redundancy. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, prerequisite, rate limit, and leg structure, but missing explanation for three optional parameters (rfqLinkId, anonymous, strategyType) and no return value/error info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains leg structure (category, symbol, side, qty). Does not cover rfqLinkId, anonymous, strategyType, leaving gaps for those 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 tool creates a new RFQ to solicit pricing from selected counterparties, specifying the verb, resource, and purpose. It distinguishes from siblings like cancelRfq and getRfqs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions prerequisite call to Get RFQ Config and provides agent hint with step-by-step guidance. Lacks negative usage conditions but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the asynchronous nature, rate limit (50 req/s), and authentication constraint (only RFQ creator). This gives the agent necessary behavioral context, though it could mention error handling or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then provides sequential details. There is some redundancy between the main text and the 'Agent hint' section, but overall it is well-structured and not excessively long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers async behavior, rate limit, and verification steps. However, it lacks details on response structure, error cases, and what the tool returns. For an execution endpoint, this is a notable gap, making it minimally viable.
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 coverage is 0%, so the description should explain parameters. It does not describe rfqId, quoteId, or quoteSide beyond their names. While the names are somewhat self-explanatory, added semantics (e.g., where to obtain these IDs) would help. The description adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute (accept) a quote to initiate the multi-leg trade,' providing a specific verb and resource. It differentiates from siblings by mentioning 'multi-leg trade' and requiring the RFQ creator, which distinguishes it from other quote-related tools like acceptNonLpQuote or applyQuote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it instructs to check Get Trade History or monitor Execution WebSocket after calling, and notes that only the RFQ creator can execute. It does not explicitly exclude alternatives but offers strong guidance on proper usage and follow-up actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it is a public endpoint, has a rate limit (1000 requests per time window), and that results show actual supply orders with potential rate changes. It does not mention idempotency or safety, but the context is adequate for a read-only query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for features, use cases, and important notes. It front-loads the purpose. While some redundancy exists (e.g., features and use cases overlap), each section adds value and the overall length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters (0 required) and no output schema. The description explains its role in the borrowing flow but lacks details on parameter constraints and return value structure. It mentions results but not their format, leaving some ambiguity for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage. The description mentions the ability to filter by currency and term and sort by rate or amount, but does not map these to specific parameter names or provide details for parameters like limit. Given the low schema coverage, the description should provide more parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries available supply orders for a specific currency and term. It specifies the verb 'Query' and the resource 'supply orders (lending offers)', distinguishing it from sibling tools like postCryptoLoanFixedBorrow or getCryptoLoanFixedSupplyOrderQuote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use the tool: 'View available lending offers before placing borrow order' and lists use cases. However, it does not explicitly state when not to use it or compare to alternative tools, though the sibling differentiation is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares it as a query (read-only) and mentions a rate limit of 5 requests per UID. With no annotations, this provides useful behavioral info, but it omits details like authentication requirements or whether data is real-time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 lines) and well-structured with a headline, features list, and use cases. Every sentence adds value, with no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with no output schema and one optional parameter, the description covers purpose, features, use cases, and rate limit. It lacks response format details but is adequate for basic understanding.
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 only parameter, 'loanCurrency', is implied by 'by currency' but lacks format, allowed values, or examples. With 0% schema coverage, the description should compensate more, but only gives minimal context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query current flexible borrow positions by currency' and lists specific features like viewing debt, interest, and hourly rate. It distinguishes from siblings by focusing on current positions, as opposed to history tools like getCryptoLoanFlexibleBorrowHistory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use Cases' section provides explicit scenarios (e.g., check debt amount, monitor interest, calculate repayment). However, it does not explicitly contrast with sibling tools or state when not to use it, though the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds valuable behavioral context: cursor-based pagination, required parameter pairing, and a rate limit of 10 req/s. This goes beyond the schema, though it does not cover all edge cases or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus three bullet points under Notes. Information is front-loaded with the main purpose, and additional details are neatly organized. No redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no output schema, and no annotations, the description provides functional context (pagination, parameter constraints) but lacks full parameter semantics, return structure, and error scenarios. More detail would aid an AI agent in correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the relationship between productId and category, and the default for orderType. However, 8 parameters exist, and only a couple are clarified; others like startTime, endTime, limit, cursor, orderId lack explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries fixed term order history with cursor-based pagination. The verb 'Query' and resource 'fixed term order history' are specific, and the tool name distinguishes it from sibling tools like getFixedTermPosition or getOrderHistory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides notes on parameter combinations (productId requires category) and default behavior (orderType not specified returns all). However, it does not explicitly state when to use this tool over alternatives like getOrderHistory or queryFixedBorrowOrders, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the need for Earn permission, sort order (newest first), and cursor-based pagination with clear usage steps. However, it does not mention idempotency, rate limits, or effects of invalid 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 concise (5 sentences) and front-loads purpose and permission. It is structured with clear sections for permissions, sorting, and pagination, though some details could be better organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has no output schema and moderate complexity, the description covers essential aspects (purpose, permission, sort, pagination) but omits parameter descriptions for timeStart, timeEnd, and limit, and does not hint at response structure.
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, but the description only explains the cursor parameter. timeStart, timeEnd, and limit are not described at all, leaving their meaning and expected format ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries personal yield distribution history specifically for Hold-to-Earn products, differentiating it from siblings like getEarnYieldHistory which may cover broader earn products. The verb 'Query' and resource are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the required Earn permission and provides pagination instructions, but does not explicitly contrast with sibling tools or specify when not to use this tool. The context implies it's for Hold-to-Earn products only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses rate limit, authentication, and behavioral constraints (defaults, time span limit). Lacks mention of output format or pagination, but covers essential traits.
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?
Description is concise (3 sentences plus a note block). Front-loads purpose and then constraints. Could be slightly more structured but is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema provided, and description does not explain return format or content of data points. Users cannot anticipate the response structure, making it incomplete for a data query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It explains defaults and time span constraint for startTime/endTime, but productId is only described by name and type. Partially compensates, leaving productId ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it queries historical NAV data points for an RWA product. Verb 'Query' and resource 'historical NAV data points for an RWA product' are specific. Sibling tools like getMarketKline or getRwaProductList are distinct, so no confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes rate limit, authentication requirement (none), and constraints on time span (max 180 days) and default values for startTime/endTime. While it doesn't explicitly state when to use vs alternatives, the context implies it's for RWA NAV data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It usefully discloses authentication requirements, parent-sub account selection behavior via parentUid, and the effect of the coin parameter on denomination. It does not cover response shape or error behavior, but for a simple query tool it provides meaningful behavioral context beyond the name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loads the core purpose, and uses bullet-point notes for additional behavioral details. Every sentence adds useful information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description covers the essential context: what is queried, authentication, parent-sub handling, and coin behavior. It does not explain the full response structure, but the phrase 'total assets overview' plus the coin denomination note gives an agent enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by explaining that the optional coin parameter denominates the total assets in that coin. This adds meaning beyond the bare string type in the schema, though it does not specify the default denomination when coin is omitted or enumerate valid coin values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Query the aggregated total assets overview for parent and sub accounts.' It clearly identifies what the tool returns and the parent/sub scope, but it does not explicitly differentiate itself from closely related siblings like getAssetOverview or getAssetList.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for querying parent and sub account aggregated assets, and notes that parentUid takes precedence when present. However, it does not explicitly state when to prefer this tool over alternatives such as getAssetOverview or getWalletBalance, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It includes rate limit (10 req/s) and states returned card states, but does not explicitly confirm read-only behavior or describe side effects. Adequate but not exhaustive.
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?
Efficiently structured: purpose sentence, states returned types and statuses, provides clear application guidance with bullet points, and ends with rate limit. No fluff.
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?
No output schema, so description should detail response fields. It mentions awardId and specCode in usage context but does not fully describe the response structure or pagination. Some gaps for agent completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains that the single parameter 'category' determines which product's coupons to query, and lists the allowed values (FlexibleSaving, DualAssets) in context. This adds meaning beyond the raw enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Query', specifies the resources (interest-rate coupons and Dual Assets reward cards), and scopes it by product category. It distinguishes itself from sibling tools like getEarnPosition and getEarnProduct by focusing on coupon listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by linking to place-order requests, but lacks explicit guidance on when to use this tool vs alternatives (e.g., getAwardInfo). No when-not-to-use or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It transparently covers rate limiting, account-type requirements, data-range restrictions, begin/end pairing, and a detailed error-code table. It does not describe response shape or pagination behavior, but it is notably transparent for a query endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a lead sentence, a rules list, and an error-code table. Each section contributes useful information, though the error table is somewhat long and the description could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers rate limits, error handling, and data constraints well. However, it leaves several optional parameters under-specified and does not explain return structure or cursor-based pagination, making non-default calls harder for an agent to construct 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%, and the description only adds meaning for begin/end pairing, the default time window, and limit range via an error code. The uid, cursor, and bizType parameters remain unexplained, and there is no mention of date formats or pagination semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: query earnings and rebate information using the exchange broker master account. The resource and scope are specific enough to distinguish it from sibling broker tools such as queryBrokerAccountInfo, queryBrokerCap, and queryBrokerAllUidDetails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The rules provide clear operational guidance: supported date range is up to one month back through T-1, begin and end must be paired or omitted, and the default window is the latest 7 days. It does not explicitly name alternative tools or when not to use it, but the constraints make the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses important behaviors: API key support, time range rule, timestamp granularity, parameter priority, and txID date restriction. Missing details like pagination behavior and rate limits, but overall strong 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, using 5 bullet points to convey key information. No fluff, each sentence adds value. The opening line is direct, and the bulleted format is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no annotations, and no output schema, the description covers critical aspects (time constraints, priority, txID restriction) but omits pagination (cursor), coin filtering, limit meaning, and response structure. Adequate for basic use but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It explains startTime, endTime (millisecond, second-level, 30-day max, defaults), id (highest priority), and txID (Jan 1, 2024 onward). However, coin, limit, and cursor are not described, leaving gaps. Partial but helpful.
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 'Query on-chain deposit records', identifying the resource and action. It distinguishes from many sibling query tools by specifying 'on-chain' and providing detailed behavioral constraints, though it does not explicitly contrast with similar tools like queryInternalDepositRecords.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: supports main/sub UID API keys, time range constraint (30 days), default behavior, parameter priority, and txID limitation. It does not specify when not to use or mention alternative tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: cursor-based pagination, filterability, default/max page size, output includes principal/interest/status, and unified account only. No annotations provided, so description carries the burden, and it does well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear introductory sentence followed by bullet-point rules. No redundant information; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a query tool with no output schema and no annotations, the description provides adequate context: output fields, restrictions, and service. Missing some details like error handling or authorization, but sufficient for typical 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?
Schema has 0% description coverage. The description compensates by explaining filter parameters (orderId, orderCurrency, term) and pagination parameters (limit, cursor). Adds meaning beyond the raw 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 it queries fixed-rate borrow contracts for matched loan details. However, it does not explicitly distinguish from sibling tools like getCryptoLoanFixedBorrowContractInfo, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Lists rules such as pagination, filters, defaults, and account type. Provides some guidance on usage but lacks explicit when-to-use or when-not-to-use compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that results are limited to 100, sorting behavior, and that it requires a unified account. However, it does not mention read-only nature, permissions, or other potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a main sentence and bullet points for rules. Every sentence adds value, and the structure is clear and front-loaded. No redundant 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 no output schema, the description lacks details about the return structure of lending offers. It does provide the service name for tracing, but omits error handling, permissions, or response format, leaving some gaps for a 5-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning by explaining the sorting fields (apy, term, quantity), sort direction values ('0' ascending, '1' descending), and the max limit. The term parameter is mentioned but not fully detailed (e.g., expected format).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the fixed-rate borrow market (supply order book) to see available lending offers. It uses a specific verb and resource, and distinguishes from sibling tools like getCryptoLoanFixedBorrowContractInfo which target different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides rules for usage (required params, sorting, limits, unified account) but does not explicitly guide when to use this tool versus alternatives. It lacks exclusion criteria or references to sibling tools for different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses the active-code filter, sub-account behavior, link generation based on user preferences, and the authentication requirement via API Key (HMAC/RSA), which goes beyond a minimal description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, well-structured with bullets, and every sentence adds meaningful behavioral or usage information. The authentication tip is clearly separated and not redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless query tool with no output schema, the description covers the main points: scope, filtering, sub-account behavior, and authentication. It does not describe the exact return structure, but that is not critical for a simple parameterless call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema already covers this fully, so the baseline is 4. The description adds no parameter-specific details, but none are needed here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries referral codes owned by the current user and their corresponding referral registration links. It identifies the specific resource and action, but it does not explicitly differentiate itself from the similarly named sibling tool 'queryReferrals'.
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 gives useful context: it is for the current user's referral codes, sub-accounts get the parent account's codes, and only active codes are returned. However, it does not explicitly say when to prefer this tool over alternatives such as queryReferrals, nor does it list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses returned information (status, exchange rate, amounts, timestamp, user ID) but does not explicitly state it is read-only or note any authorization requirements or rate limits. Adequate but not exhaustive.
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?
Well-structured with headers and bullet points, front-loading purpose. Every sentence adds value, no fluff. Concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately covers returned fields. Covers query options and use cases. Could mention if there are rate limits or pagination, but for a simple query tool, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning by distinguishing tradeNo (system-generated) from merchantRequestId (custom) and stating at least one is required. This goes beyond the schema which only provides names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries detailed information and status of a specified trade. It uses a specific verb (query) and resource (trade), and the context of sibling tools like getOrderDetail and queryTradeHistory helps differentiate it, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit constraints (at least one query parameter required) and lists three specific use cases (poll for status, reconcile trades, display details). Does not explicitly state when not to use, but guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses rate limit (5 req/s) and behavior for removeRate and removeType parameters. However, without annotations, it does not disclose side effects, required permissions, or failure states for a withdrawal operation. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs front-load purpose and cover optional parameter semantics with no redundant words. Every sentence adds value.
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?
No output schema provided. Description covers optional parameters but omits required ones and return value. For a financial withdrawal, more context (e.g., post-withdrawal state, error conditions) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates well by explaining removeRate (integer percentage 1-100, omitting or 0 means 100% full redemption) and removeType (defaults to Normal, proportional redemption). However, it does not describe the three required parameters (productId, orderLinkId, positionId).
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 'Withdraw funds from a Liquidity Mining pool position', specifying the verb (withdraw) and resource (Liquidity Mining pool position). This distinguishes it clearly from sibling tools like addLiquidity and executeLPRedeem.
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?
No explicit guidance on when to use this tool versus alternatives (e.g., executeLPRedeem). The description implies usage context through parameter details but lacks when-not-to-use or alternative tool suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that it automatically adds margin from available balance to prevent liquidation, works only in isolated margin mode, and requires linear contracts. However, it does not mention side effects (e.g., consumption of balance) or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two paragraphs: first paragraph states purpose and conditions, second paragraph is an agent hint with usage details. Front-loaded, no fluff. Could integrate hint into first paragraph but still well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple toggle with no output schema, the description covers main points: what it does, when it works, and parameter meanings. Does not elaborate on immediate effects or compare to related tools, but sufficient for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains autoAddMargin values (1 enable, 0 disable) and positionIdx meaning (1=buy, 2=sell in hedge mode). But it does not explain 'category' (only linear) or 'symbol' format. Adds value for 2 of 4 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 tool toggles the auto-add-margin feature for a position, includes specific verb 'toggle', resource 'auto-add-margin feature', and constraints (isolated margin mode). It distinguishes from siblings like 'addMargin' or 'addReduceMargin' which are different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to toggle auto-add-margin on isolated margin positions' and specifies parameter settings for enable/disable and hedge mode. Does not explicitly list alternatives, but provides clear context for when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool configures MMP, requires all parameters, and specifies that frozenPeriod can be '0' for permanent freeze. It also mentions rate limits and decimal constraints. However, it does not describe side effects, authorization needs, idempotency, or what happens upon invalid input.
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 reasonably concise, with the purpose stated upfront. The agent hint repeats some information, but it's still succinct and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose and parameter details well, but given no annotations and no output schema, it lacks information about the return value, error conditions, and overall effect. It is adequate for a simple configuration tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds crucial meaning: it specifies that 'window' and 'frozenPeriod' are in milliseconds, and that 'qtyLimit' and 'deltaLimit' are positive numbers with max 2 decimals. This goes well beyond the schema's raw string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Configure' and the resource 'Market Maker Protection parameters for options trading'. It distinguishes itself from the sibling tool 'resetMmp' by mentioning the configuration purpose and the reset endpoint.
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 states that all parameters are required and gives a hint about frozenPeriod and the rate limit. However, it does not explicitly specify when to use this tool versus other configuration tools or alternatives, and lacks guidance on prerequisites or scenarios where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool places real orders, the response is only an acknowledgment, and that external verification (subscribeOrder or REST) is needed. It does not mention idempotency, failure modes, or whether modifications are atomic, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, the first presenting the purpose and the second a bold warning. It is front-loaded with key information, though it could be structured more formally with bullet points or sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 parameters, 2 required), no output schema, and high schema coverage, the description adequately covers the tool's operation and verification needs. It lacks error handling details or common constraints, but is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 16 parameters with descriptions, achieving 100% coverage. The description adds minimal value beyond the schema, only reiterating that symbol, side, quantity, and price need user confirmation. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (amend/modify), the resource (existing unfilled or partially filled order), and the context (via WebSocket on Bybit V5 unified account). It effectively distinguishes this tool from its siblings like createOrder and cancelOrder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an important warning to confirm order details with the user before calling, but it does not explicitly state when to use this tool versus alternatives like the non-WebSocket amendOrder or when not to use it. It mentions subscribeOrder for verification but lacks comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It discloses many behavioral traits: repayment logic (full vs partial), conversion fees, time restrictions, and priority ordering of liabilities. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and front-loads the purpose. However, it is somewhat lengthy; some details (e.g., conversion fee limits) could be condensed without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is remarkably complete. It covers input semantics, behavioral rules, side effects (conversion, fees), and temporal constraints. An agent has sufficient context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the meaning of coin and amount through rules (e.g., 'If neither coin nor amount is provided, the system repays all liabilities'), but it does not describe the repaymentType parameter (enum: ALL, FIXED, FLEXIBLE). Partial coverage leaves gaps.
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 'Manually repay the liabilities of Unified account' with a specific verb and resource. However, it does not explicitly distinguish this tool from sibling tools like accountNoConvertRepay or quickRepayment, which have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed rules about when to use coin/amount parameters and lists blocking conditions (e.g., time block). However, it does not guide the agent on when to choose this tool over alternatives like accountNoConvertRepay or quickRepayment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: cancels orders, closes positions, requires running state, includes rate limit. With no annotations, this covers most behavioral traits needed for an agent to assess impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise; three brief paragraphs front-load the main purpose and provide additional details without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Good completeness for a mutation tool with no output schema and no annotations. Covers behavior, prerequisites, post-action, and rate limit. Lacks explicit return value description, but partly mitigated by post-action hint.
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 has 0% coverage, so description must compensate. It explains bot_id source but only vaguely describes stop_type as 'indicates the reason' without explaining enum meanings (0-15). This leaves ambiguity for a critical parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it closes a running futures combo trading bot by canceling orders and closing positions. Does not explicitly differentiate from sibling tools like closeGridBot, but the name and context sufficiently target combo bots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: only running bots can be closed. Includes a direct agent hint explaining how to obtain bot_id and suggests checking getComboDetail afterward. Also mentions rate limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that the tool creates a binding, forwards to downstream validation, and may fail for specific business reasons presented as MCP tool errors. It mentions the success response includes a link and guides the agent's reply. However, it doesn't explicitly state destructive nature or auth requirements, but the creation act implies mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long due to a multi-paragraph agent hint that includes detailed workflow instructions, success message templates, and link construction. While valuable, it is not concise; the front-loading is good but the later sections could be condensed. Every sentence earns its place but overall density is high.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers business logic and failure modes well. It provides success message formats and link construction, but fails to describe the tool's actual return value (likely a binding ID or status). The agent hint focuses on user interaction rather than tool output, leaving a gap in understanding what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It defines providerMark as the target and gives an e8 amount example for investmentE8 (e.g., 30000000000 for 300 USDT). However, it doesn't explain the concept of e8 or the minimum value from the schema. It adds some value but not exhaustive documentation of parameter semantics beyond what the schema node provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states the tool creates a Copy Trading TradFi follow binding with specific parameters (providerMark and investmentE8). It unambiguously identifies the verb 'create' and the resource 'Copy Trading TradFi follow binding', distinguishing it from siblings like createCopyTradeBind by targeting TradFi specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use only after obtaining an exact providerMark, not inferring from display name; minimal endpoint does not support optional parameters like TP/SL; and the agent hint outlines a complete workflow for recommending and binding, including when to call other endpoints. It also lists common business failures, helping the agent decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the response is an acknowledgment and advises using WebSocket for confirmation. It covers support for various order types and categories. However, it omits behavioral details like authentication requirements, rate limits, or potential side effects on positions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and breaks down by category. It front-loads the core purpose. Although it is moderately long due to the complexity of the tool, it remains efficient and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (34 parameters, no output schema, no parameter descriptions in schema), the description addresses the main use cases and key parameters. However, it does not fully cover all parameter interactions or provide examples for all order types (e.g., conditional orders, TP/SL setups), leaving some 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 0%. The description adds meaning for key parameters like orderFilter, positionIdx, orderLinkId, and orderIv, and explains category usage for TradFi tokens. However, many parameters (e.g., timeInForce, triggerPrice, takeProfit) remain unexplained, so the description only partially compensates for missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Place a new order on the Bybit exchange' and elaborates on supported categories (spot, linear/inverse, options) and specific token examples. It effectively distinguishes from sibling tools like amendOrder, cancelOrder, etc., by focusing on order creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool ('to place a new buy or sell order for spot, linear, inverse, or option products') and includes TradFi examples. It lacks explicit exclusion criteria or alternative tools for specific scenarios, but the context is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds rate limit (50 req/s) and the constraint about not quoting own RFQ. It does not disclose the result of a successful quote (e.g., does it create a pending quote, require confirmation?) or potential side effects, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and each sentence adds value. Bullet points clarify the lists, and the agent hint is efficient. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers input constraints and behavioral rules well. It lacks an explanation of what happens after quote submission (e.g., returns quote ID, requires confirmation) but is otherwise adequate for an input-focused tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for quoteBuyList and quoteSellList (maker execution direction) beyond the schema, though other parameters like quoteLinkId, anonymous, and expireIn are not explained. With schema coverage at 0%, more parameter documentation would be beneficial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool submits a quote for an existing RFQ, specifies the required at least one of quoteBuyList or quoteSellList, and differentiates from siblings like createRfq (creates RFQ) and cancelQuote (cancels quote).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this to respond to an RFQ with pricing and provides constraints (cannot quote own RFQ, ensure collateral for spot). However, it does not contrast with siblings like acceptNonLpQuote or applyQuote, leaving some ambiguity about when to prefer this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses rate limit, default behavior, pagination limits, and max time span. It does not mention read-only nature or effects on state, but as a query tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three short paragraphs for purpose, rate limit, and agent hints. No fluff, front-loaded with key information, and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not describe the return values or structure. While it explains parameters and usage well, it omits what the response contains, leaving some uncertainty for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter schema coverage is 0%, but the description adds meaning beyond the raw schema: it mentions filtering by currency (with examples), time range, and pagination via cursor and limit. It also explains defaults and constraints, compensating for the low 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 it queries interest and borrowing records for the unified account, with filtering and pagination. It distinguishes from siblings by specifying the scope, but does not explicitly differentiate from similar borrowing history tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The agent hint explicitly states when to use it ('review borrowing costs and interest history'), provides currency examples, and mentions default time range and max span. It lacks explicit contraindications or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It adds value by mentioning rate limit (10 req/s) and that borrowing limits are shared across parent and sub-accounts. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the purpose, and includes a rate limit and agent hint. It is efficiently structured for agent use.
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 query with one optional parameter, the description covers main use cases and lists key fields. However, without an output schema, it could describe the return structure more fully. Adequate but not exceptional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'currency' has 0% schema coverage, and the description adds 'Pass currency to filter for a specific coin'. This adds meaning beyond the schema, but lacks format or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries collateral information including borrowing rates, limits, and settings, with per-coin data. It is distinct from sibling tools like getBorrowHistory or getAccountInfo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an agent hint explicitly stating when to use the tool (check borrowing rates and collateral status) and how to filter with the currency parameter. It lacks explicit when-not-to-use but is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It uses 'Query' implying read-only, explains statuses (Processing, Filled, Rejected), and discloses a constraint (Max 7-day range). This provides adequate behavioral transparency for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a clear purpose, output summary, agent hint, constraint, and status meanings. Each sentence adds value without unnecessary fluff.
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 8 parameters, no output schema, and no annotations, the description covers purpose, usage, and constraints but omits details on pagination (limit, cursor) and time parameter formats. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It mentions four filter fields (category, symbol, status, blockTradeId) and implies time-range constraints, but does not describe limit, cursor, or exact format for startTime/endTime. Partial coverage adds value but not fully compensatory.
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 'Query the history of position move (block trade) orders' with a specific verb and resource, distinguishing it from siblings like movePosition and getOrderHistory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The agent hint explicitly tells when to use the tool: 'Use this to check status and history of move position requests.' It also lists filterable fields, providing clear usage context, though it does not explicitly mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It accurately describes the tool as a query (read) operation with no side effects. It explains the concept of side markets but does not detail response format or constraints. For a simple query tool, this is adequate but minimal.
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 five sentences, front-loaded with the main purpose. It includes examples and a hint without unnecessary fluff. Could be slightly more concise, but each sentence adds value.
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 query tool with no output schema, the description explains the purpose and parameter mapping. However, it does not describe the expected output structure (e.g., fields in the market list). While the tool name hints at the return, additional detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must add parameter meaning. It provides a crucial mapping: 'eventType=1 refers to FIFA_2026'. This is valuable beyond the schema's enum constraint. However, it does not describe the parameter's purpose beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Query' and the resource 'list of side/related markets'. It distinguishes from siblings like getPredictionMatchList by specifying that this tool returns additional markets beyond match outcomes, with concrete examples (top scorer, group winners).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'discover additional trading opportunities beyond match outcome predictions'. It specifies that eventType=1 refers to FIFA_2026. It does not explicitly exclude alternatives, but the use case is well stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it does disclose that results are paginated, status-filterable, and optionally narrowed by projectId or activityCoin, plus the status value semantics. However, it does not describe response contents, ordering, error behavior, or auth expectations, leaving some behavioral transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is an excellent front-loaded summary, and the agent hint is useful, but the same facts (list Puzzle activities, status filter, projectId, cursor/limit) are covered twice in the description and hint, creating redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter list endpoint with no annotations or output schema, the description gives enough to invoke it correctly: required status, optional filters, and pagination mechanism. It lacks a return-shape mention and explicit alternative routing, but these are minor for this simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must supply meaning, and it does: status values are mapped to upcoming/ongoing/ended, projectId is identified as the project code to use for lookups, and cursor/limit are tied to pagination. activityCoin is explained only by its name ('narrow results by ... activity coin'), and the limit default/maximum is left to the schema, so it is good but not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific declarative: 'Returns a paginated list of Puzzle activities filtered by status,' naming a concrete resource (Puzzle activities), the operation (list), and the primary constraint (status). It is easily distinguishable from the many sibling project-list tools such as getLaunchpoolProjectList and getTokenSplashProjectList because 'Puzzle activities' is a distinct domain, and the optional filters are named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use it: to browse available Puzzle activities or look up details of a specific project. The agent hint adds operational guidance on filtering by status, passing projectId, and using cursor/limit for pagination. It does not name alternatives or exclusions, which would elevate it further, but the use cases are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It lists the data returned (effective shares, in-flight amounts, bonus, NAV, hold value) and includes a rate limit, but does not explicitly state it is a read-only operation or discuss side effects, authorization, or data freshness. The implication is clear, but not fully explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: one for purpose and one for rate limit. Every word adds value, and there is no fluff or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description adequately covers what the tool returns by listing key fields. It is missing potential details like pagination or maximum results, but for a simple query it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% by default. The description adds no parameter information because none exist. According to guidelines, 0 parameters yields a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Query the user's RWA holding positions' which uses a specific verb and resource, clearly stating the action and object. It distinguishes from sibling tools like getRwaOrderList (orders) and getRwaProductList (products) by focusing on positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. However, the context of sibling tools (e.g., getRwaOrderList, getRwaProductList) implies it is for positions, but no direct guidance on when to choose this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation ('Retrieve') and notes the scope (unified account). However, it does not disclose any side effects, required permissions, or error conditions, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that front-load the purpose and provide critical details (unified account, parameter behavior). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one optional parameter and no output schema, the description covers purpose, scope, and parameter behavior adequately. Missing details like return format or authentication requirements, but these are not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains the optional parameter 'currency' by stating that omitting it returns settings for all currencies, adding valuable behavior beyond the schema type definition.
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 'Retrieve the current automatic repayment mode settings for margin trading accounts,' providing a specific verb (Retrieve) and resource (automatic repayment mode settings). This distinguishes it from many similar 'get' siblings by specifying the exact data returned.
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 gives context: 'Unified account only' and behavior when currency is omitted. However, it does not explicitly state when not to use this tool or suggest alternatives, which would be helpful given the large number of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does this well by stating the inclusion rules: only registered activities before announcement time, deposit-only tasks excluded, and the tradeTask object showing progress and estimated reward. It lacks explicit read-only/no-mutation and rate-limit details, but the disclosed constraints are meaningful.
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 front-loaded with an accurate purpose sentence and useful eligibility conditions. However, the 'AI agent can use this' sentence and the 'Agent hint' paragraph repeat essentially the same instruction, adding redundancy without much new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-required-parameters read query with no output schema, this description gives enough context: what the response represents, which activities are included, and what the tradeTask object conveys. It could include return-envelope or error details, but those are not critical for an agent to select and invoke this endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 0%, so the description must compensate. The phrase 'Filter by projectId or activityCoin to narrow results' adds basic filter semantics, but it does not explain the format, source, or possible values of these parameters beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Returns the authenticated user's participation and trade-task progress for Token Splash activities.' This clearly distinguishes it from siblings like getTokenSplashProjectList, which would focus on project-level data rather than user progress.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent to use this endpoint to fetch the current user's trade progress and says to filter by projectId or activityCoin. However, it does not mention alternative sibling tools or explicitly say when not to use this endpoint, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behaviors: private endpoint (authentication), hourly floating rate, repay anytime, interest calculated hourly, multiple collateral support, and rate limit. Important notes about LTV and checking rates add transparency. Could mention if loan is immediately disbursed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Features, Use Cases, Important). Every sentence provides value, and the length is appropriate for the tool's complexity. No redundant or vague statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description references other endpoints (loanable-data) and provides enough context for a borrowing tool. However, it lacks output details (what is returned) and does not cover error cases or prerequisites beyond LTV. Given no output schema, more completeness would be beneficial.
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?
With 0% schema description coverage, the description must explain parameters. It mentions loanCurrency, loanAmount, and collateralList only as parameter names without format, constraints, or examples. The 'Important' note about LTV hints at their use but does not detail parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Borrow crypto with flexible hourly interest rates.' It specifies the action (borrow), resource (crypto loan), and key differentiator (flexible vs. fixed, hourly rates). This distinguishes it from sibling tools like postCryptoLoanFixedBorrow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use Cases' section provides clear scenarios: short-term borrowing, avoiding fixed-term commitment, and leveraging hourly rate changes. It also advises checking loanable-data for current rates. However, it does not explicitly state when not to use or compare with fixed borrowing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool is read-only (query), imposes a rate limit, restricts account types, and notes missing entries for unconfigured accounts. It lacks details on pagination behavior, but the cursor parameter in the schema partially covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear purpose statement followed by bullet points for additional rules. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain the return value (rate limits per UID) but does not. It covers account eligibility and rate limit but misses response details and parameter formats, leaving gaps for the 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?
The description does not explain the three parameters (uids, limit, cursor) beyond what the schema provides. Since schema coverage is 0%, the description should compensate but fails to add meaning, e.g., missing format for uids or usage of cursor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: querying UID-level rate limits for all master and subaccounts using the master account. The verb 'query' and resource 'UID-level rate limits' are specific, and it distinguishes from siblings like getRiskLimit by focusing on broker accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: only exchange broker accounts can call it, rate limit of 1 req/s, and that accounts without configured rate limits won't appear. However, it does not explicitly state when not to use or mention alternatives, so it's not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses pagination behavior, filtering capabilities, default and max limits, and account restriction. It does not mention rate limits or authentication, but the information provided is sufficient for basic usage understanding.
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 relatively concise: one sentence for purpose, a bulleted list of rules, and a service line. The service line ('Service: bizasset-uta-loan-prod') is potentially unnecessary. Overall, it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains pagination and filtering but does not mention what fields are returned in the response. Since there is no output schema, the agent is left guessing about the response format. This is a significant gap for a query tool, making it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists filterable parameters (orderId, orderCurrency, state, term) and cursor/limit but does not explain their meaning or format. The state enum is not described. This adds some value but falls short of fully compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Query fixed-rate borrow order history', which clearly identifies the verb (query) and resource (fixed-rate borrow order history). It distinguishes from sibling tools like getCryptoLoanFixedBorrowOrderInfo (single order) by implying listing/history. The filtering and pagination rules further clarify its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: cursor-based pagination, filtering options, default page size, maximum limit, and a constraint ('Unified account only'). However, it does not explicitly state when to use this tool over alternatives like getCryptoLoanFixedBorrowOrderInfo or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses important behavioral traits: API key permission needed, rate limit of 10/s, Unified wallet requirement, and conversion range. It does not cover error behavior or result formatting, but covers key operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a single sentence for main purpose followed by bullet points for constraints. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and constraints adequately for a simple query tool, but lacks details on return value structure. Since there is no output schema, the agent may not know what fields are returned, making it somewhat incomplete.
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 has 0% description coverage and no descriptions for parameters. The tool description indirectly hints at the purpose of parameters (e.g., accountType likely refers to wallet type) but does not explicitly explain them, leaving the agent dependent on naming conventions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: querying small-balance coins eligible for dust conversion and supported to-coins. It provides specific resource details and additional constraints like permission and wallet type, distinguishing it from generic query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes usage constraints such as required API permission, rate limit, and wallet type, but does not explicitly mention when to use this tool versus alternatives like SmallAssetConvert or QuerySmallAssetConvertOrder.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains conditional behavior (unfreeze vs. reset) and states that counters go to 0 regardless. It also provides a rate limit of 5 req/s. However, it does not mention any side effects or authorization requirements, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It starts with the main action, then explains behavior in two states, followed by a rate limit note and an agent hint. Every sentence adds value, and no redundant information is present.
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 (single required parameter, no output schema), the description covers the core behavior and usage context. However, it lacks explanation of the parameter and does not mention prerequisites (e.g., whether MMP must be enabled). It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only mentions that the tool requires the baseCoin parameter but does not explain what baseCoin represents. With 0% schema description coverage, the description should define the parameter. The agent must infer its meaning from the tool name and context, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Reset MMP freeze state and clear trading history counters.' It distinguishes between frozen and unfrozen states, and the agent hint specifies its use case for unfreezing or resetting counters. This differentiates it from siblings like setMmp and getMmpState.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The agent hint explicitly says when to use this tool: to unfreeze an MMP-frozen account or reset counters. It does not explicitly mention when not to use or name alternatives, but the context of sibling tools (setMmp, getMmpState) implies the distinction. Clear but could be more explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly explains behavioral details: repayment timing (0 and 30 minutes every hour), repayment amount calculation (min of available spot balance and current liability), and the effect of omitting the currency parameter (applies to all currencies). Since no annotations are provided, this context is essential and well-covered.
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 structured with a clear opening statement, followed by a detailed explanation and bullet points for currency behavior. It is concise (about 100 words) and avoids unnecessary repetition. Minor improvement could be merging the timing and amount details into a single paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and parameter behavior well. However, it does not mention the return value or error cases (e.g., what happens if autoRepayMode is invalid or currency not found). For a tool with no output schema, this information could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the tool description adds value by explaining the meaning of autoRepayMode ('1' enables, '0' disables) and the behavior when currency is omitted (applies to all currencies) versus specified (only that currency). This clarifies parameter usage beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set spot automatic repayment mode.' It explains the mechanism (timed repayments at 0 and 30 minutes each hour) and distinguishes itself from sibling tools like accountRepay (manual repay) and getSpotMarginTradeAutoRepayMode (query) by focusing on enabling/disabling auto-repay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to enable or disable automatic repayments) but does not explicitly contrast with alternatives like manual repay (accountRepay) or querying the current mode (getSpotMarginTradeAutoRepayMode). No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes rate limit (10 requests/s/UID) and response includes check_code for error indication. No annotations provided, so description carries burden. Would benefit from mentioning read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with four sentences and an agent hint. Front-loaded with main purpose. Rate limit info included. Could be slightly more compact but effective.
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?
Covers purpose, usage order, and error indication via check_code. Missing details on success response structure (e.g., the allowable ranges format) and no output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 has 0% description coverage and 17 parameters. Description lists some parameter categories (investment, profit, etc.) but does not explain each parameter. Partially compensates by stating validation returns ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates input parameters for creating a futures grid bot and returns allowable ranges. It distinguishes itself from sibling tools like createFGridBot and validateGridInput (likely for spot).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use before creating a grid bot and includes an agent hint. Does not explicitly state when not to use or compare to alternatives, but context implies futures grid only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Discloses real order modification, WebSocket usage, and acknowledgment-only response. Does not fully cover limits or order types (e.g., conditional orders) but provides useful warnings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an IMPORTANT note, all front-loaded with essential information. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main behavioral aspects: batch modification, WebSocket, acknowledgment, verification need. Missing mention of max batch size (in schema) and applicability to conditional orders, but overall sufficient given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3 applies. Description adds no extra meaning beyond schema; does not explain parameters further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (batch amend), resource (multiple existing unfilled or partially filled orders), and context (WebSocket request on Bybit V5 unified account). It distinguishes from siblings like 'amendOrder' and 'wsAmendOrder' by specifying batch operation and order state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit user confirmation requirement before calling and clarifies that response is only an acknowledgment, with alternative verification methods. Lacks explicit when-not-to-use versus alternatives like batchCancelOrders, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool places/modifies real orders (though it cancels), and that response is acknowledgment-only. However, it lacks details on idempotency, error handling for non-existent orders, or specific behavior for partially filled orders. The warning about confirming details adds some transparency but is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two short, clear sentences. The first sentence states the purpose and scope, and the second provides critical usage guidance. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately addresses the acknowledgment-only nature and directs to other methods for verification. It covers the key behavioral aspect (real order impact) and usage prerequisite (confirmation). It could mention cancellation irreversibility or rate limits, but overall it is sufficient for a cancellation tool with low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 5 parameters. The description adds no additional meaning beyond the schema; the generic warning about confirming symbol, side, quantity, and price is partly irrelevant for cancellation (side, quantity, price are not required). Thus the description does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cancel an existing unfilled or partially filled order'), the resource ('order'), and the protocol ('via WebSocket on Bybit V5 unified account'). It distinguishes from siblings like 'cancelOrder' (likely REST) and 'batchCancelOrders' by highlighting the WebSocket nature and specific use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: confirm symbol, side, quantity, and price before calling, and notes that the response is only an acknowledgment, advising to use subscribeOrder or REST endpoints for verification. It implies when to use (for unfilled/partially filled orders) but does not explicitly state when not to use (e.g., for orders already filled).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that it supports querying sub UID balance with master API key and enumerates parameter dependencies. The verb 'query' implies it is a read operation with no side effects, which is transparent enough.
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 short, uses a paragraph with bullet points, and is front-loaded with the core purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no output schema, and no annotations. The description covers usage scenarios well but does not describe the return format or any pagination/limitations. For a query tool, some mention of the response structure would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 8 parameters with 0% schema description coverage, but the description adds meaning to several key parameters (e.g., required ones, memberId for sub UID, toMemberId+toAccountType for cross-account). However, it does not cover all parameters like `withBonus` or `withTransferSafeAmount`, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries the balance of a specific coin in a specific account type, and mentions additional capabilities like sub UID balance and cross-account transferable balance. It distinguishes itself from sibling tools like getAccountInfo, queryBalance, etc., which are more general.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific conditions for using the tool, such as requiring `accountType` and `coin`, and notes when `memberId` or `toMemberId`+`toAccountType` are needed. However, it does not explicitly state when not to use it or mention alternatives, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses rate limits (10 req/s), compliance/KYC checks, and explains bot behavior including the meaning of parameters like martingale_mode and auto_cycle_toggle. It also notes the need for the bot_id for subsequent calls.
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 fairly long but well-structured into paragraphs covering behavior, parameters, preconditions, and hints. Some redundancy (e.g., mentioning getFMartLimit twice) could be trimmed, but it remains clear.
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 17 parameters, no output schema, and no annotations, the description covers the core bot logic and parameter meanings well. However, it lacks details on error responses, exact return structure, or edge cases, leaving some gaps for a complex create endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It explains the key parameters (symbol, mode, leverage, price_float_percent, etc.) and interprets enums (e.g., martingale_mode: 1=Long, 2=Short; auto_cycle_toggle=1 for restart). This compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates a futures Martingale trading bot and explains the bot's behavior (opens position, adds on dips/rises). It distinguishes itself from sibling tools like closeFMartBot and getFMartDetail by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to call getFMartLimit first to validate parameters, providing clear when-to-use guidance. It does not explicitly exclude alternative creation tools, but the context is specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the response is an acknowledgement only, orders may be rejected asynchronously, and max 50 open orders per account. It also mentions authentication and symbol constraints. This is valuable behavioral context beyond a simple 'create order'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for usage scenarios, important notes, and agent hint. Every sentence adds value, no redundancy. Concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions async acknowledgement but not response format. It covers some parameters and behavioral constraints but omits details on error handling or success confirmation. Adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains orderLinkId, timeInForce, and price (for limit orders), but does not describe side, orderType, or qty. Partial coverage adds some value but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new spread trading order,' which is a specific verb and resource. It distinguishes from siblings like 'amendSpreadOrder' and 'cancelSpreadOrder' by focusing on creation. The usage scenarios further clarify the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit usage scenarios (opening new spread position, using orderLinkId, timeInForce) and important notes (async response, max 50 orders, price required for limit orders). It provides good context but does not explicitly compare to alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses: private endpoint (authentication required), rate limit (5 requests per time window per UID), behavioral traits (returns 0 if withdrawal would cause liquidation, calculated to maintain LTV below liquidation threshold), and the purpose of preventing liquidation. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with 'Features', 'Use Cases', and 'Important' headings. It is front-loaded with the main purpose. It is concise, though there is minor redundancy (e.g., 'Prevents accidental liquidation' and 'Prevent liquidation by validating withdrawal amounts' say similar things). However, it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with one parameter and no output schema, the description is complete. It explains the return value (maximum amount or 0 if unsafe), covers authentication and rate limiting, and provides use cases. It adequately informs an AI agent without leaving major gaps.
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 only parameter 'currency' is a string. Schema coverage is 0%, so the description should add meaning. However, the description does not explain the parameter beyond its name. The currency is likely the collateral currency, but no details on format, allowed values, or examples are provided. Minimal value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource statement: 'Query the maximum amount of collateral that can be redeemed (withdrawn) for a specific currency.' This directly explains what the tool does and distinguishes it from sibling tools like getCryptoLoanCommonCollateralData or getCryptoLoanCommonLoanableData.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use Cases' section provides clear contexts: 'Check how much collateral can be safely withdrawn', 'Ensure sufficient collateral remains after redemption', 'Prevent liquidation by validating withdrawal amounts'. It does not explicitly list when not to use or alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses no authentication required, data order (reverse chronological), and data format (5-element array). Lacks details on rate limits or error handling, but overall transparent for a read-only query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and clear sections, but slightly redundant (reverse chronological mentioned twice). Front-loaded main purpose. A bit lengthy but justified by complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately explains tool purpose and relationship to siblings, but lacks parameter semantics despite 0% schema coverage. Missing details on parameter formats and pagination. Output schema not provided, but description partially compensates with data format.
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 has 0% description coverage. Description does not explain parameters (category, symbol, interval, start, end, limit) beyond what is in the schema. Only mentions interval implicitly via enum list. Agent hint is generic. Needs explicit parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Query historical mark price klines used for margin and liquidation calculations' and distinguishes from siblings: 'Do not use this endpoint for regular trading price candles — use getMarketKline instead. Do not use this endpoint for index price candles — use getIndexPriceKline instead.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists use cases (risk management, charting) and provides clear exclusions with alternatives, including supported products (USDT contract, USDC contract, Inverse contract).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description bears full burden. It discloses real-time behavior, potential latency during volatility, that openOnly=1 includes recently terminated orders (up to 500), and pagination via cursor. This is comprehensive for a read tool, though it omits permission requirements or response details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs plus hints, totaling about 90 words. It is efficient and front-loaded with the core purpose. The structure is logical, though the TradFi mapping could be integrated more cleanly.
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 many sibling tools (e.g., getOrderList, getAllOrders, getPendingOrders), the description only distinguishes from getOrderHistory. It does not mention return format, pagination limits beyond 500, or authorization. For a tool with 10 parameters and no output schema, more context would be helpful.
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?
With 0% schema description coverage, the description must compensate, but it only explains constraints for a few parameters (e.g., linear/inverse require at least one of symbol/baseCoin/settleCoin; openOnly behavior). Many parameters like orderId, orderLinkId, orderFilter, limit, cursor lack any explanation. The description adds limited value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Query real-time unfilled or partially filled orders.' It specifies the resource (open orders) and action (query), and distinguishes from getOrderHistory for historical orders. The TradFi mapping further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this endpoint to list currently active (open) orders.' It names the alternative getOrderHistory for historical orders, and gives conditional requirements for linear/inverse. The TradFi mapping also helps specific users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the auth requirement and the parameter-dependent behavior of returning all base coins when baseCoin is omitted. 'Query' implies a read-only operation, and no side-effect or mutation concerns are raised.
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 short and front-loaded: the primary purpose appears in the first sentence, and the two behavioral notes each earn their place. There is no redundant wording or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-optional-parameter read tool with no output schema, the description covers the key information: what it returns, authentication, and the baseCoin default behavior. It could be more detailed about the response shape or rate limits, but those are not essential for correct invocation here.
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 only defines baseCoin as a string with no description, so the description's note that omitting baseCoin returns all base coins adds real semantic value. It clarifies optionality and default behavior, though it does not specify the expected coin symbol format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query') and clearly identifies the resource ('portfolio margin information') plus the main contents (wallet balance, margin rates, asset PNL range). It does not explicitly distinguish itself from related siblings like getWalletBalance or getVipMarginData, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational context: authentication is required, and baseCoin is optional with a defined fallback ('returns all base coins'). It does not name alternatives or state when not to use this tool, but the usage context is explicit enough for an agent to proceed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description bears full burden. It discloses that positions are open/unresolved only, includes details like shares held, market value, P&L, and event info. Does not mention rate limits or authentication beyond 'authenticated user', but is transparent about read-only nature and content.
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 somewhat lengthy but each sentence adds value: purpose, return content, usage guidelines, and agent hint. Could be slightly more concise, but no waste.
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?
No output schema, but description explains position contents well. Covers purpose, context, and usage, but lacks parameter documentation. For a tool with 3 optional params, the agent needs more detail to use them 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?
Input schema has 3 optional parameters (limit, direction, pageIndex) with 0% schema description coverage. The description does not explain any parameter meanings, usage, or how they affect the query. This is a significant gap for the agent.
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 'Query the authenticated user's current open prediction positions' with a specific verb and resource. It distinguishes from sibling tool getPredictionPositionHistory by noting 'For historical positions, use getPredictionPositionHistory'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'AI agent should call this before placing a sell order to confirm the user holds sufficient shares, and to display the current portfolio.' Also gives an alternative for historical positions and specific advice to 'Check availableSize before selling.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description discloses permission requirements, rate limiting, caching behavior, position limit, and per-position result handling. It does not mention idempotency but the purpose implies reads. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-organized into paragraphs for purpose, permission, rate limit, and important usage details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description covers purpose, permission, rate limit, caching, ordering, and per-position results. It lacks output format details but that is not required without an output schema.
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 coverage is 0%, so description must compensate. It only notes 'Max 5 position IDs per request' for positionIds, but does not explain the category enum or what positionIds represent. Insufficient detail for both 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 tool queries estimated redemption amounts for Smart Leverage/Double Win positions. It distinguishes itself from other tools by specifying the exact use case and that it must be called before placing a Redeem order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit prerequisites (Earn permission), rate limits, and the critical timing constraint (must call before redeem, cached for 10 minutes). It does not explicitly state when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses it is a read operation (retrieve), applies only to unified accounts, and gives the formula. It does not detail permissions or rate limits, but for a simple query this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a bullet point. The purpose is front-loaded, and every sentence adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not describe the return value format. It explains the input and calculation, but an agent would need to infer the output type. Lacks details on response structure or potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'currency' is not described in the description beyond being for a specific cryptocurrency. With 0% schema coverage, the description partially compensates by referencing 'spot coin' and 'coin borrow amount', but does not explicitly define the parameter's meaning or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the available amount for repayment in spot margin trading, using a specific verb ('Retrieve') and resource ('available amount'). It distinguishes from siblings like getSpotBorrowQuota by focusing on repayment, not borrowing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Unified account only', indicating when to use this tool. Provides the calculation formula, but does not explicitly contrast with alternative tools (e.g., accountRepay, quickRepayment) or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses latency during high volatility, cursor-based pagination, and no authentication required. It implicitly suggests read-only nature but does not explicitly state it. Overall, good transparency for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with clear sections (purpose, usage, notes, agent hint). Front-loaded with main purpose. Slightly verbose but still efficient; every sentence adds value.
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?
Covers purpose, usage, pagination, latency, and auth. However, lacks parameter descriptions and response structure details beyond mentioning return fields. Completeness is adequate but not thorough given the tool's complexity.
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 coverage is 0%, and the description minimally addresses parameters. It explains cursor usage for pagination but does not describe symbol, baseCoin, or limit parameters. The agent hint mentions response fields but not request parameters, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: querying spread instrument specifications including contract type, trading status, tick size, order limits, and leg details. It effectively distinguishes itself from the sibling tool getSpreadTickers for real-time prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (before orders, for precision validation, component retrieval), when not to use (real-time prices), and indicates alternative (getSpreadTickers). Includes pagination guidance with cursor usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively conveys behavioral traits: rate limit (50 req/s), field query priority, time restriction (last 3 months for link IDs), and that results include per-leg info. It could mention idempotency or that it only returns filled/failed trades (inferred from status enum), but overall well-disclosed.
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 structured with clear sections (purpose, pagination, priority, rate limit, hints). It is somewhat lengthy but front-loaded with key info. Every sentence adds value, though it could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description must explain return values. It mentions per-leg info with examples (orderId, execFee) and cursor-based pagination. However, it lacks details on response structure or format. Fairly complete for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, thus description must add meaning. It explains rfqLinkId/quoteLinkId time restriction and field priority, but introduces a 'category' parameter not present in the schema (e.g., 'use category=spot'), causing confusion. Other parameters like traderType and status lack detail. Valuable but incomplete.
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 'Query RFQ trade execution history' with optional filtering, which is a specific verb+resource. It distinguishes from sibling tools like queryTradeHistory by focusing on RFQ trades, and provides field query priority, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an agent hint to use this tool after calling Execute Quote, and notes time restrictions for rfqLinkId/quoteLinkId. However, it does not explicitly mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the burden of disclosure. It mentions the tool is a read operation for the user's own payment methods, which is sufficient, but doesn't elaborate on authentication, rate limits, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and every sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description identifies the 'id' field's usage but does not fully describe the return structure or other fields. With no output schema, it could provide more detail about the expected response, though it's adequate for a simple list retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (trivially). The description adds no parameter info, which is acceptable as there are none. Baseline 4 applies per guidelines for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves payment methods configured in P2P, using a specific verb 'Get' and resource 'payment methods'. It distinguishes itself from sibling tools like getAds or postAd by focusing on payment data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the returned 'id' is used as 'paymentIds' when posting or updating ads, providing direct usage guidance. It doesn't explicitly state when not to use it, but for a simple getter, this is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses fee-free nature, price constraints, leg limit, and processing status. Does not discuss idempotency, reversibility, or exact response fields, but adequately covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-organized paragraphs with front-loaded main action, followed by constraints and hint. No fluff, but could be slightly more concise by merging repetitive points. Generally effective.
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?
Covers prerequisites, constraints, and post-action hint, but lacks explanation of response format. Without output schema, the description should detail what the agent can expect upon success or processing. Adequate but with gaps.
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 coverage is 0%, so description must compensate. It adds context for the list parameter (legs, price range) but does not explicitly define fromUid, toUid, or list structure. Incomplete parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Transfer positions between two unified trading accounts (UIDs) without fees.' Specifies verb, resource, and key condition. Distinguishes from siblings like getMovePositionHistory by focusing on execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit hint for sub-account movement, required master API key, mode requirements (UTA, one-way mode), max legs (25), price range (95%-105%), and follow-up action (check getMovePositionHistory). Covers when to use and constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the rate limit (5 req/s), required fields, and behavior for each order type (e.g., 'deduct settlement coin', 'lock shares'). However, it does not mention whether the operation is reversible or what happens on failure beyond the error code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, bullet points, and clear hierarchy. It front-loads the core action and then provides essential details efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two order types, multiple parameters), the description covers the main behavioral differences and required constraints. Without an output schema, it could mention what the response contains (e.g., order ID), but it does point to the Get Order endpoint for tracking.
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 the description adds meaning where the schema does not. It explains the conditional nature of stakeAmount and redeemShares based on orderType, and notes that orderLinkId must be unique. However, it does not describe productId, coin, or accountType in detail beyond stating the default for accountType.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool places a Stake or Redeem order for an RWA product, with detailed explanations of what each action does (deduct settlement coin for Stake, lock shares for Redeem). It distinguishes itself from other order tools by specifying RWA context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use Stake vs Redeem and provides important notes about orderLinkId uniqueness and error handling. It references the Get Order endpoint for tracking, but does not explicitly exclude use cases or compare with siblings like createOrder or placeEarnOrder.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behaviors: no penalty, partial/full support, interest calculation up to repayment, and a rate limit. It lacks details on collateral release or post-repayment state but provides solid 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 concise, well-structured with a header, bulleted features, and use cases. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While it covers features and use cases, it lacks details on the response/outcome of the mutation, and prerequisites like having an active loan, making it moderately complete for a mutation tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description only implicitly references parameters (loanCurrency and amount) through features, but does not specify formats, allowed values, or examples, leaving ambiguity for agents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool repays a flexible loan using the loan currency, with specific features and use cases that distinguish it from siblings like postCryptoLoanFlexibleRepayCollateral or postCryptoLoanFixedFullyRepay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context via features and use cases (e.g., repay anytime, partial or full repayment), though it does not explicitly exclude or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses the return fields, data aggregation sources, and account type restriction. It is transparent about the tool's read-only nature 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 brief and well-structured, with a clear main sentence followed by bullet-pointed rules. Every sentence adds value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description lists the specific fields returned and notes aggregation sources and account type. For a simple query with one parameter, it covers the essential context adequately.
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 schema has 0% description coverage, and the description only restates that 'currency' is required without adding format or constraints. It provides minimal additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries the borrow liability breakdown for a specific coin, detailing fixed-rate and flexible-rate liabilities. It distinguishes itself from sibling borrow tools by specifying the breakdown and aggregation sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes rules that specify required parameter and the condition 'Unified account only', providing clear context for when to use the tool. However, it does not explicitly mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full behavioral burden. It describes default behavior (last 7 days), constraints (time interval), and pagination. It implies a read operation without side effects. Lacks explicit mention of idempotency or rate limits, but still good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 short sentences) and well-structured with bullet points. Every sentence adds value, and it is front-loaded with the purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains pagination (nextPageCursor) which hints at response structure. It covers all needed usage constraints. It could mention what fields are returned, but for a query tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It adds meaning for 3 of 4 parameters: createTimeFrom, createTimeTo, and cursor. The 'limit' parameter is not described. Overall adds significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries transaction records of the funding account. It provides specific resource (funding account) and action (query records), distinguishing it from other query tools like queryBalance or queryTrade. However, it does not explicitly differentiate from siblings, so a 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: time parameters must be used together and interval cannot exceed 7 days, with default to last 7 days. It also mentions cursor-based pagination. However, it does not specify when not to use this tool or alternatives, so 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies read-only behavior with 'retrieves' and provides a rate limit of 10 qps per UID. Since no annotations exist, the description carries the full burden. It could be improved by explicitly stating no side effects, but the current wording is sufficient for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a field list, usage statement, rate limit, and agent hint. It is appropriately sized and front-loaded with key details. Slight room for improvement by combining the agent hint into the main usage guidance, but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter query tool with no output schema, the description sufficiently covers what the tool returns (listing many fields) and how to obtain the required grid_id. It lacks mention of pagination or error handling, but for a simple detail query, it is contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no description in schema), so the description must compensate. It explains that grid_id is a numeric ID obtained from createGridBot or grid list queries, adding context beyond the raw integer type. However, it does not specify format or constraints, making it adequate but not exemplary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves comprehensive details of a spot grid bot, listing specific fields (symbol, price range, profit metrics, status, etc.). It distinguishes from sibling tools like getFGridDetail by specifying 'spot grid bot', ensuring the agent selects the correct tool for spot grid details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when you need to check the current state, performance, or configuration of a specific grid bot' and provides guidance on obtaining grid_id. However, it does not explicitly mention when not to use it or point to alternative tools like getFGridDetail for futures grids, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It details sorting order (newest first), pagination limits (max 50, default 20), status meanings and error codes, and the role of parentOrderId. Lacks rate limits or data freshness, but comprehensive overall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with headings and bullet points. Efficient overall, though the agent hint partly repeats the 'When to use' section. Each part serves a purpose, and the length is appropriate for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 8 parameters, the description covers purpose, usage, pagination, and statuses. However, missing parameter descriptions for over half the parameters and no indication of response shape leaves gaps. Adequate but not exhaustive.
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 coverage is 0%, so the description must compensate. It explains the status enum values fully and notes strategyId is required, but leaves other parameters (symbol, BeginTimeE0, EndTimeE0, cursor, StrategyType) completely undescribed. Incomplete compensation for missing schema docs.
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 'Retrieve a list of child orders created by a strategy with detailed execution information.' The verb 'retrieve' and specific resource 'child orders of a strategy' clearly differentiate it from sibling tools like getOrderList or getOpenOrders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a dedicated 'When to use' section with specific scenarios (view orders, check rejections, analyze prices, monitor real-time, debug) and an agent hint on requiring strategyId, plus guidance to ask for it if missing. Provides explicit context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behavioral constraints: master UID requirement, validation of parent-child relationship, and unavailability for certain sub-account types (custodial, Copper bound) and UAE coin restrictions. This is strong transparency for a query tool, though it omits details on response format or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence and four bullet points. Every sentence adds value—main action, auth requirement, and key restrictions. No redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the tool's essential constraints and context well. It explains when and for whom this tool works. However, it lacks details on the return format or any pagination/error behavior, which would be helpful for a complete understanding.
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%, yet the description does not explain the parameters (coin, chainType, subMemberId). It relies on the parameter names being self-explanatory. While the tool name and constraints add context, a good description would explicitly describe each parameter's meaning and allowed values to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Query deposit address for a sub-account' which is a clear verb and resource. It distinguishes itself from sibling tools like queryDepositAddress by emphasizing 'sub-account' and 'master UID API key only', making the specific scope obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: requires master UID API key only and lists multiple restrictions (custodial sub-accounts, Copper custody, UAE coin restrictions). However, it does not explicitly name alternative tools for when these restrictions apply (e.g., queryDepositAddress for main account), leaving usage guidelines slightly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses behavioral traits: pagination mechanics, account types, statuses, mode determination logic, entrust trading support, and filtering. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely verbose (over 600 words) with unnecessary implementation steps (process flow 1-11). While structured with headers, it is not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (pagination, types, statuses, mode logic) and lack of output schema, the description is highly complete, covering all necessary context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains pageSize default/max/auto-adjust and nextCursor usage (first page = 0). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries all sub-accounts of the master account with pagination. It is specific, but does not differentiate from sibling tools like querySubMembers.
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 notes that only master account can call and lists use cases, but does not explicitly state when not to use this tool or compare with alternatives like querySubMembers or listSubAPIKeysV5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses institutional requirements, product types, time window range, need to activate DCP stream, and propagation delay. However, it does not mention whether the setting overwrites previous values, what happens if called multiple times, or any additional side effects beyond the cancellation 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 structured with bullet points and an agent hint, making it easy to scan. It front-loads the main purpose. However, the agent hint partially repeats the first sentence, and some information (like propagation delay) could be integrated without repeating the overall purpose. Minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers prerequisites, products, time window range, activation steps, and propagation delay. It lacks details on response format or error handling, but for a simple configuration endpoint, it is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explicitly links 'product' to options, derivatives (futures), and spot products, and 'timeWindow' to a range of 3-300 seconds. While it doesn't give a detailed explanation of each parameter's purpose beyond the main description, it adds enough context for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures the time window for automatic order cancellation on WebSocket disconnection. It specifies the verb 'Configure' and the resource 'DCP time window', distinguishing it from sibling tools like getDcpInfo (read) and subscribeDcp (subscription). The agent hint reiterates the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: institutional users only, must be enabled via account manager, and sequential steps (set then activate stream). It does not explicitly state when not to use or mention alternatives, but the sibling context and the explicit 'Agent hint' guide usage adequately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behavioral traits: main UID requirement, sub-account restriction, default FUND wallet, UTA 2.0 restriction, and KYC limits. It does not mention immediate effect or response, but for a setter this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by four bullet points, no redundant information. It is front-loaded with the main purpose and efficiently lists constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with one parameter and no output schema, the description covers purpose, restrictions, and defaults. It lacks response details but is complete enough for an agent to understand usage.
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 coverage is 0%, so description must explain parameters. It mentions 'FUND' as default and 'CONTRACT' is restricted, but 'CONTRACT' is not an option in the enum. It does not explain what 'UNIFIED' means, leaving ambiguity for the sole parameter.
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 'Set the default account type for receiving on-chain deposit funds,' specifying the verb 'Set' and the resource 'default account type for on-chain deposits.' This distinguishes it from sibling tools like accountBorrow or addLiquidity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage constraints: only main UID API key can call, sub-accounts disallowed, and KYC restrictions apply. It also notes the default behavior and limitations for UTA 2.0 users. However, it does not explicitly compare with alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the modes, supported product type, and preconditions. It could be improved by describing failure behavior (e.g., what happens if prerequisites are not met), but overall it gives good 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: two sentences plus a hint. Every sentence adds unique value, and the structure is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and limited schema coverage, the description provides essential context: supported assets, prerequisites, and parameter priority. It lacks return value or error details, but for a simple switch operation, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates well. It explains the mode values (0 and 3), the roles of symbol and coin, and the priority rule. It could explicitly mention that category must be 'linear', but this is implied by the USDT perpetual reference.
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 switches between one-way (mode=0) and hedge (mode=3) position modes, and specifies that only USDT perpetual contracts support hedge mode. However, it does not explicitly distinguish from the sibling tool 'setHedgingMode', which may have a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: when to switch modes, the prerequisite that no open positions or orders exist, and the constraint that symbol or coin must be provided with symbol taking priority. It does not, however, specify when not to use this tool versus alternatives like setHedgingMode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly states the tool places/modifies real orders, that the response is just an acknowledgment, and directs users to verify order status via other means. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs. The first states the core purpose, the second adds critical usage guidance. Every sentence is meaningful and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 30 parameters and no output schema, the description adequately explains the acknowledgment nature and where to verify orders. It lacks details on error handling or return format, but covers essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema, except the note to confirm certain parameters. The parameter descriptions in schema are adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it places new orders via WebSocket, using a specific verb and resource. It distinguishes from REST equivalents (createOrder) but does not explicitly differentiate from other WebSocket order tools like wsAmendOrder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The IMPORTANT note tells users to confirm symbol, side, quantity, and price before calling, and explains that the response is only an acknowledgment, advising to use subscribeOrder or REST endpoints for verification. It does not provide when-not-to-use or alternatives for amendments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses key behaviors: using spot balance, time-based restrictions, interest calculation timing, repayment order, and currency restrictions. This is adequate for understanding the tool's operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a front-loaded purpose statement followed by bullet-point rules. Every sentence adds value without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 3 parameters, no output schema, and no annotations, the description provides sufficient context for a manual repay tool. It covers core behavior, rules, and service identifier. Lacks explanation of return values or confirmation, but the tool's simplicity makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must add meaning. It explains coin and amount behavior (optional, mutual exclusivity) but does not describe the repaymentType enum, leaving part of the semantics unexplained. The description adds some value but is incomplete.
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 'Manual repay without asset conversion (lossless repay)', specifying the action (repay) and resource (debt currency). It distinguishes from siblings like accountRepay by emphasizing no conversion, making the purpose specific and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit rules for when to use, such as behavior when coin is provided without amount, prohibition during 04:00-05:30, and non-acceptance of BYUSDT. While it does not explicitly state when not to use this tool versus alternatives, the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that this commits real assets, imposes a rate limit (5 req/s), and explains idempotency via orderLinkId. Does not detail failure modes or return values, but for a financial mutation tool, the key behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and clear sections (parameter rules, rate limit, agent hint). Every sentence adds value, no fluff. Front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description covers the main action, conditional logic, rate limit, and a critical safety warning. Missing details on productId and leverage, and no return value description, but overall sufficient for an agent to use correctly with user confirmation.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 0%, so description must compensate. It explains conditional requirements for quoteAmount/baseAmount and their associated account types, and orderLinkId's idempotency and length limit. However, leverage is not mentioned at all, and productId lacks explanation despite being required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Inject funds into a Liquidity Mining pool', specifying the verb (inject) and resource (liquidity mining pool). It distinguishes from siblings like 'removeLiquidity' (opposite action) and 'reinvestLiquidity' (different behavior).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides conditional parameter requirements (quoteAmount/baseAmount, account types) and an explicit agent hint: must ask user for confirmation before executing, due to committing real assets. This guides when-not-to-use automatically, though alternative tools are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool may fail with a 503 status if the bot is mid-cycle, and mentions the rate limit. With no annotations provided, it does not explicitly state whether the operation is irreversible or if it has destructive side effects, but the context of 'closing' implies finality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It starts with the purpose, then details the required parameter, constraints, and an agent hint. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema, the description covers the key aspects: parameter meanings, operational constraints (closeable state, error case), rate limits, and an agent hint. It is sufficient for the agent to use the tool correctly, though it could mention what happens on success or additional error statuses.
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 significant meaning for the close_mode parameter, explaining the three modes (1,2,3) with their effects, and provides an agent hint. The bot_id parameter is not described, but it is self-explanatory as the bot's identifier. Given the schema coverage is 0% (though actually partial), the description compensates well for close_mode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Closes a running DCA bot.' It specifies the resource (DCA bot) and action (close), distinguishing it from sibling close tools for other bot types (e.g., closeComboBot, closeGridBot).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: it requires a close_mode, notes that the bot must be in a closeable state (and may fail with 503 if mid-cycle), and gives a rate limit of 3 qps. It also offers an agent hint for using close_mode=3. However, it does not explicitly compare to alternative close tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses settlement modes, required bot state, and rate limit of 3 qps per UID. No annotations provided, so description bears full burden. Could mention return behavior or error handling, but overall adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with action, uses clear structure with line breaks and bullet-style list for modes. Agent hint adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential behavioral aspects (action, modes, state constraints, rate limit) given no output schema or annotations. Lacks details on error cases and grid_id source, but complete enough for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. Provides detailed semantics for close_mode (enum meanings and hints), but grid_id is not explained beyond its implied role as bot identifier. Adds value for one of two 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?
Clearly states the tool closes a running spot grid bot, with specific verb and resource. Distinguishes from sibling close tools for other bot types (e.g., closeComboBot).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists required close_mode with explanations of each option, and states the bot must be in NEW or RUNNING state. Includes agent hint for optimal mode selection. Lacks explicit exclusion of alternatives but context implies scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses async execution, trade statuses, and prerequisites. No annotations present, so description carries full burden. Minor gap: does not mention behavior if already confirmed.
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?
Well-structured with sections (Important, Trade Status, Use Cases). Every sentence adds value, front-loaded with main purpose, no fluff.
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?
Covers async behavior and statuses, but lacks parameter details. Given 0% schema coverage and no output schema, more param explanation needed for full 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?
Schema coverage is 0%; description only mentions merchantRequestId and webhookUrl in use cases but does not explain quoteTxId, subUserId, or detailed formats for any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool confirms a quote and executes a conversion trade. It uses specific verbs and distinguishes from siblings like 'createQuote'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (within validity period), asynchronous nature, trade query endpoint, webhook recommendation, and lists concrete use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers rate limit (3 qps per UID) and a specific error case (ban with code 421). However, it does not explain other potential errors, idempotency, or whether the bot is active immediately after creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose, parameter list, prerequisites, return value, error handling, rate limit, and agent hint. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (creation with multiple constraints), the description covers prerequisites, constraints, return values, error handling, and rate limits. It lacks explanation for two parameters (toolsDiscoveryParameter, channel) but otherwise is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning for frequency_in_second (common values), pairs (per-round investment amount), and mentions optional max_invest_amount. It does not explain toolsDiscoveryParameter or channel, but those may be internal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Creates a DCA bot' and specifies the resource '(bot) that automatically invests at regular intervals.' It distinguishes from sibling tools like closeDCABot by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit prerequisites (authentication, KYC, valid pairs, min 10 sec frequency, max 5 pairs) are provided. It lacks explicit 'when not to use' but the constraints and sibling list imply the tool is for creation only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return content, risk flags, status, and the showMessage notification behavior. However, it does not explicitly state read-only nature or lack of side effects, but as a query tool this is implicit.
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?
Description is verbose and contains repetitive information, especially in the 'Agent hint' block which largely duplicates the main paragraph. Important info is front-loaded, but redundancy reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description covers return fields, notification behavior, and prerequisites. Missing explicit error handling or authentication notes, but for a read-only query tool the coverage is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description adds value by telling agents to get chainCode and tokenAddress from specific list responses. However, it mentions a showMessage parameter not in the schema, causing confusion. No format or constraint details added beyond source guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries detailed on-chain token information, listing specific return fields. It distinguishes from siblings by explicitly directing to getBizTokenPriceList for prices and getBizTokenList for browsing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call when user asks about token details, project info, or risk status. Provides prerequisite parameters from getBizTokenList or getAssetList. Clearly states what not to use for (prices, browsing) and gives alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds meaningful detail: supported coins only, uppercase requirement, the exact availability formula, and rounding behavior ('borrow precision, rounded down'). This is strong, though it does not explain error cases or the response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the main purpose, and the bulleted rules are scannable and free of filler. Every sentence adds information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter query tool with no output schema, the description is largely complete: it defines input constraints and the exact meaning of the returned inventory value. It does not explicitly describe the response format, but the formula and precision rules make the behavior sufficiently clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does by explaining that the single 'currency' parameter must be an existing, uppercase coin supported by flexible crypto loan. This adds meaning beyond the bare string type in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Query'), a specific resource ('available lending pool inventory'), and a specific product type ('flexible loan'). This clearly distinguishes it from sibling tools like getCryptoLoanFixedAvailableInventory and getSpotMarginTradeFlexibleAvailableInventory.
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 phrasing 'for flexible loan' implies when to use this tool, and the rules list validity constraints. However, it does not explicitly contrast with alternatives or state when not to use it, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: hourly vs daily returns, descending order, range limit, and optional authentication. No annotations to contradict, and no destructive behavior to warn about.
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 and well-structured with clear sections and bullet points. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple query, the description covers all essential aspects: purpose, categories, ordering, range, and authentication. Sufficient for agent decision-making.
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 has 0% description coverage, and the description only mentions parameter constraints indirectly (max range). Missing details on startTime/endTime format (e.g., Unix timestamp vs ISO) and productId semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query historical daily APR for a product' and distinguishes two product categories (FlexibleSaving and OnChain) with different time granularities, differentiating it from sibling tools like getEarnYieldHistory or getTokenHistoricalApr.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: public endpoint, descending order, and max 182-day range. Lacks explicit alternatives or when-not-to-use, but the simplicity of the query makes it adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses pagination behavior, optional filtering, and the response shape (pools with APR and staking totals). It does not explain the meaning of the required status integer values or any auth/rate-limit traits, but it is reasonably transparent for a read-only list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and stays compact. The agent hint adds practical guidance, though there is minor redundancy between the first paragraph and the hint about status filtering and pools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, filters, pagination, and basic output shape, but with no output schema and no enums it leaves important gaps: status integer meanings, exact response field names, and cursor handling details. This is adequate but not fully complete for an agent needing to call it correctly without extra assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains status filtering, activityCoin, projectCode, and limit/cursor pagination, adding meaning beyond the bare schema. The main omission is the mapping of status values (0/1/2) to concrete activity states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Returns a paginated list of Launchpool activities filtered by status.' It also names the optional filters (activity coin, project code) and the key return content (pools array with APR and staking totals), making the tool's role distinct from Launchpool user-history siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The agent hint explicitly says to use this endpoint for browsing Launchpool activities by status, explains filtering by activityCoin, and instructs cursor + limit for pagination. It gives clear context but does not state when not to use it or name alternative tools for user-specific history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description thoroughly discloses the tool's behavior: it returns detailed info, includes outcome token IDs, current prices, and statistics. It also explains the slug priority and hasMoreMarkets parameter effect. No contradictions.
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 contains some redundancy (e.g., 'Agent hint' repeats earlier info) and could be more streamlined. It is adequately structured but slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description provides a fairly complete picture: what the tool does, when to use it, parameter usage hints, and sibling avoidance. It could mention response format or rate limits, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds meaning by explaining slug is for human-readable lookups (takes priority), eventId as alternative, and hasMoreMarkets to include sub-events. However, it doesn't provide exhaustive details beyond the schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves detailed information about a prediction event, including markets, outcome tokens, prices, and trading statistics. It distinguishes from sibling tools by specifically advising not to use getPredictionMarketList for individual event details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (before placing orders to get token IDs and prices), explains priority of slug over eventId, and provides agent hints. It also includes a clear directive to avoid getPredictionMarketList for this purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns token symbol, code, and blockchain list, and mentions the Phase 1 limitation (USDC only). No side effects are expected for a read-only query.
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 contains some repetition, e.g., 'AI agent should call this before executing a trade' and 'Agent hint: Use this endpoint...'. It is clear but could be more concise by merging similar instructions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return values (token symbol, code, blockchain list) and how to use the token code in buy requests. It covers the essential context for a simple query tool, though it does not mention pagination or error handling.
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 no parameters (empty schema, 100% coverage), so the description does not need to add parameter details. The baseline for 0 parameters is 4, as the description adds value by explaining the output context, even though it doesn't describe 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 tool queries available payment tokens for prediction market trading, specifying that it returns token symbol, code, and supported blockchain list. It distinguishes from sibling tools like getPayTokenList by explicitly targeting prediction market, and notes Phase 1 supports USDC only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises the AI agent to call this before executing a trade to verify supported payment tokens, and provides a specific hint about using it before placing a prediction market buy order. While it doesn't explicitly exclude other contexts, the purpose is clear enough to guide appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that data is returned in reverse chronological order and the output format (5-element array). It does not mention rate limits or error handling, but for a read-only kline endpoint, the coverage is good. A minor gap is lack of mention of pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and bold headings, making it scannable. It is front-loaded with the core purpose. However, the 'Agent hint' at the end is redundant with earlier content, adding slight unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a kline query tool with 6 parameters and no output schema, the description covers purpose, usage context, output format, ordering, authentication, and differentiation from similar tools. It lacks explicit parameter descriptions but the standard nature of kline parameters partially compensates. Overall, it is fairly complete.
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, so the description must add meaning. However, it does not explicitly explain any parameters (e.g., start, end, limit). The meaning of symbol and interval is implied by the endpoint type, but start/end and limit are standard but not described. The 'Agent hint' is vague and doesn't compensate. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries historical premium index price klines and explains they represent the basis between mark and index price for funding rate calculations. It explicitly distinguishes from sibling tools like getMarketKline, getMarkPriceKline, and getIndexPriceKline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (analyzing funding rate basis, researching mark-index relationship, building charts) and explicitly states when not to use it (for trading/mark/index price candles) with references to alternative endpoints. Also notes that no authentication is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses supported products, pagination (cursor-based), authentication requirement (none), and returned data (tiered risk limits, margin requirements, leverage caps). Lacks detail on pagination limit defaults or error handling, but sufficient for core behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points, front-loaded purpose, and clear sections. Repetition of 'category is required; symbol is optional' appears twice, but overall concise and each sentence adds value.
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?
No output schema exists, so description must compensate. It states returns all risk tiers and includes margin requirements and leverage caps, but lacks detail on response structure, error conditions, or pagination behavior. Adequate for a query tool but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains category (required), symbol (optional), and mentions cursor-based pagination but does not describe cursor parameter usage or effects. Provides enough context for two of three parameters, leaving cursor partially explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries tiered risk limit parameters for perpetual and futures contracts, listing specific parameters (position size limits, margin rates, leverage). It distinguishes from sibling tool getInstrumentsInfo by explicitly stating not to use for instrument-level leverage filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear use cases (before large positions, check max leverage, margin rates) and explicitly states when not to use (instrument-level leverage filter) with alternative tool name. Agent hint reinforces usage before setting leverage or large orders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses supported products, response format (3-element arrays), limit of 50 levels per side, and no authentication required. It covers key behavioral traits but lacks details on rate limits or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points, sections, and clear headings. It front-loads the purpose. A minor redundancy (repeated array format) prevents a perfect score, but it remains concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, no output schema), the description covers supported products, response format, limit, and alternatives. It explains the RPI-specific feature well. However, it could clarify the category parameter enum values and provide a brief example response for 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?
Input schema has 0% description coverage, so the description must compensate. While it mentions supported products (mapping to category) and limit (max 50 levels), it does not explicitly describe each parameter or their formats. The agent must infer which parameter corresponds to product category and the meaning of symbol.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves orderbook depth data with RPI order sizes, distinguishing it from the standard orderbook tool getOrderbook. It uses specific verbs and resources, and explicitly differentiates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios (e.g., needing RPI liquidity, microstructure analysis) and a clear 'Do not use' directive with the alternative getOrderbook. An agent hint reinforces when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, description discloses key behavioral traits: returns two types of amounts (with/without borrowing), indicates borrowable coin, and states applicability. Clearly communicates read-only nature implicitly.
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?
Concise three-part structure: main line, bullet points of key returns, agent hint and TradFi note. Each sentence adds value, no redundancy. Front-loaded with primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with 3 parameters and no output schema, description covers purpose, return content, usage context, and constraints. Lacks explicit return format or edge cases but sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It adds meaning for symbol via 'applies to xStock tokens only', but for category it only repeats schema enum ('spot'), and side is unaddressed. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Query' and specific resource 'borrowing quota for spot margin trading'. Description details returns (max tradeable quantity/amount with/without borrowing, which coin can be borrowed) and explicitly limits to spot category, distinguishing from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Agent hint explicitly states when to use: 'check how much you can trade before placing a spot margin order'. Also notes non-applicability to equity/commodity perpetuals, providing clear context but no named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses time range logic (7-day window, precedence of orderId/orderLinkId), retention policy (cancelled orders stored 24h), authentication requirement, and response contents (both-leg details). Lacks explicit mention of pagination or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (Usage Scenarios, Time Range Logic, Important) and an agent hint. It is front-loaded with the main action, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 params, no output schema, and no annotations, the description covers core behavior well: purpose, filtering rules, special cases, and response hint. It is mostly complete but omits details on pagination (cursor/limit) and the role of symbol/baseCoin.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 0%, so description must add meaning. It explains key parameters: orderId/orderLinkId precedence, startTime/endTime behavior. However, it does not describe symbol, baseCoin, limit, or cursor explicitly, though the agent hint mentions 'All parameters are optional'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Query historical spread trading orders including filled, cancelled, and rejected orders.' It differentiates from siblings like 'getOrderHistory' (regular orders) and 'getSpreadOpenOrders' (open orders) by focusing on historical spread orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios: review past activity, look up by ID, query within time range. It implies when to use this tool over alternatives (e.g., for spread orders vs. regular orders) but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does a solid job: it reveals pagination via cursor + limit, enumerates status meanings (0=upcoming, 1=ongoing, 2=ended), and clarifies optional narrowing by projectId or activityCoin. It does not cover response shape or ordering, but the core call behavior is disclosed.
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 front-loaded and readable, but it repeats the same idea ('Returns a paginated list...' vs 'Use this endpoint to list Token Splash activities') and includes the meta sentence 'AI agent can use this...' that adds little operational value. Tightening to two sentences would make it stronger.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paginated read/list tool with no output schema, the description covers the required status parameter, optional filters, and pagination mechanism, so an agent has what it needs to call the tool correctly. It is less complete on return structure, but the 'list of Token Splash activities' phrasing plus schema constraints make this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by decoding status values, explaining projectId as the specific-activity lookup, and describing cursor + limit pagination. activityCoin is only restated by name, and limit defaults are left to the schema, but the key semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names the exact operation ('Returns a paginated list of Token Splash activities') and identifies the primary filter (status), immediately differentiating it from generic list tools and from siblings like getTokenSplashUserActivityParams. The optional narrowing by project code or activity coin further defines its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells an agent when to use it: to browse available Token Splash activities or look up a specific project by code, and the Agent hint reinforces the endpoint's role. It does not name alternative tools to rule out, but for this list operation the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses that the endpoint is public and requires no authentication. It also notes the deprecation of the collateralRatio field. While it doesn't mention rate limits or other constraints, it covers key behavioral traits for a read-only query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, but the 'Agent hint' partially repeats information about the deprecated field and usage. However, it remains front-loaded with the core purpose and is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two optional parameters and no output schema, the description provides adequate context: purpose, return fields, deprecation notice, and authentication requirement. It doesn't explain the return format, but for a query tool this is acceptable without an output schema.
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 the parameters 'vipLevel' and 'currency' only in passing ('by VIP level and/or coin'), without explaining their types, allowed values, or defaults. This leaves significant ambiguity, especially since both parameters are optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries margin data for Unified accounts by VIP level and/or coin. It lists specific return fields like borrowing availability, interest rates, collateral settings, and liquidation order. This distinguishes it from siblings like getCollateralInfo or getTieredCollateralRatio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an 'Agent hint' that explicitly tells when to use the tool (to check borrowing terms) and when not to (the collateralRatio field is deprecated, suggesting use of getTieredCollateralRatio instead). This provides clear guidance and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description discloses access type and rate limit, but does not detail side effects (none expected), data freshness, pagination, or other behavioral traits. Some additional context would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence for purpose and three bullet points for rules. No wasted words, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter, no output schema, and no annotations, the description covers purpose, access, filtering, and rate limit. It omits return format details, but overall is complete enough.
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 only shows productId as string with no description, but the description explains its optionality and effect ('if omitted, returns all products'), adding meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'institutional loan product information', and specifies included fields (leverage, risk lines, trading pair whitelists), distinguishing it from sibling tools which are mostly mutations or other queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides rules including public access, guest allowance, optional productId filter, and rate limit, giving clear context on when and how to use. It lacks explicit alternatives or when-not-to-use guidance, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description covers privacy (authentication required), rate limit (1 per time window per UID), return value (adjustId), and behaviors for add vs remove. Missing details on side effects like fees or impact on loan terms, but overall covers key behavioral traits well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (Features, Use Cases, Important) and bullet points. Some redundancy between Features and Important (both mention add/remove). Generally concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description mentions returning an adjustId. Lacks details on error scenarios, response structure, and prerequisites beyond 'no active loans'. Could be more complete for a mutating tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description partially compensates by explaining the 'direction' parameter (1=add, 2=remove). However, it does not elaborate on 'currency' format or 'amount' semantics (e.g., units, precision). Adds value but not fully compensating for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool adjusts collateral for a specific currency to manage LTV ratio. Distinguishes from siblings by focusing on LTV adjustment, with explicit features for adding or removing collateral. Verb 'adjust' and resource 'collateral' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases (adding collateral near liquidation, removing excess, rebalancing, risk management) and important notes on direction values, margin requirements, and conditions for removal. Effectively guides when to use the tool and when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It adds a rate limit disclosure ('1 request per UID') but does not detail side effects like what happens to the old loan or collateral. Some behavioral insight is provided but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Features, Use Cases) and is concise, using bullet points and short sentences. Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers purpose, use cases, rate limit, and parameter hints. It lacks details on return values or prerequisites but is sufficient for a renewal tool. Slightly more could be said about preconditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining that 'collateralList' is for adding additional collateral and 'loanId' is the existing loan. This adds meaning beyond the raw schema, helping an agent understand parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Renew an existing loan by creating a new loan to repay the old one' and lists features and use cases, clearly identifying the tool's purpose and distinguishing it from sibling tools like renewFixedBorrow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Use cases are provided ('Extend loan term to avoid liquidation', 'Add more collateral to improve LTV'), giving clear context for when to use. However, it does not explicitly mention when not to use or compare to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses important behaviors (read replica usage, withdrawType mapping, AML record field replacement, status indicator). It does not mention rate limits or explicit read-only nature, but overall provides good 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 concisely structured with bullet points, front-loading the main purpose. Each section adds distinct value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains operational details (read replica, type mapping, special cases) that affect the query results. It does not describe the output fields, but the business rules provide sufficient context for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains startTime, endTime constraints and withdrawType enum values, but does not describe withdrawID, txID, coin, limit, or cursor parameters. Thus, it adds partial value but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Query withdrawal records') and provides specific constraints (Master UID API key only, max 30-day range, business rules). This differentiates it from sibling tools like queryDepositRecords or queryBalance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context (API key requirement, date range limits, default behavior for missing startTime/endTime). However, it does not explicitly state when not to use this tool or point to alternative tools among the many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes a rate limit (20 requests/second/UID/path) which is a useful behavioral disclosure. Since annotations are absent, the description carries the full burden; it does not mention error handling or empty results, but for a read-only query, the disclosure is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three short paragraphs covering purpose, rate limit, and usage hint. No redundancy and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and usage but lacks detail on the data structure (output has no schema) and does not explain the biz_type enum mapping. For a tool with 2 params and no output schema, more information about return data format and enum values is needed.
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 description gives examples (SPOT_GRID, BTCUSDT) but the schema uses numeric enums for biz_type (0-8) without explaining the mapping. This mismatch confuses the agent. Schema coverage is 0%, and the description does not clarify the enum values or the meaning of symbol beyond an example.
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 that the tool returns recommended strategies and market mode for bot creation given biz_type and symbol. It distinguishes from sibling tools by specifying the exact context (bot creation page) and output (up to 6 strategies, market_mode).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The agent hint explicitly states when to call this tool (when user is creating a bot and knows bot type and trading pair) and how to use the returned data (pre-select grid direction, present strategies as starting params). It provides clear, actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that the tool toggles between 'auto-adjusted' and 'rejected' behaviors for orders exceeding limits. It also mentions a rate limit of 5 req/s. However, it does not detail whether the change is reversible or if it affects existing orders, which would be helpful for a configuration tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with a clear purpose statement, then rate limit, then an agent hint. Every sentence adds value, though the 'Agent hint' label could be removed to save space. It is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and no output schema, the description covers the purpose, parameter semantics, rate limit, and suggests a sibling tool for checking current config. It does not describe return values, but for a configuration tool this is acceptable. Overall, it provides sufficient context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema. It explains that 'category' refers to product categories (linear, inverse, spot) and notes that settings for linear or inverse apply to all futures. It clarifies that 'modifyEnable=true' means auto-adjustment and 'false' means rejection. With 0% schema coverage, this fully compensates.
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 'Configure price limit action behavior per product category' with a specific verb and resource. It explains that it controls whether orders are auto-adjusted or rejected. However, it does not explicitly distinguish this tool from other configuration sibling tools like setLeverage or setMarginMode, which share the same 'set' prefix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear hint on when to use the tool: 'Use this to control how orders are handled when they exceed price limits.' It explains the boolean parameter's effect and suggests using getUserSettings to check current config, offering an alternative. It does not include explicit 'when not to use' conditions, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: permission requirements, rate limiting, wallet restrictions, transaction limits, unsupported account types, potential under-execution of amounts, and load balancing strategy. This exceeds expectations for 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 compact and well-structured: a clear opening sentence followed by six bullet points, each adding distinct information without redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description covers the main purpose and constraints but falls short on parameter semantics and detailed return structure. It explains return values minimally ('quote ID and per-coin conversion details') and leaves out parameter validation contexts.
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 coverage is 0%, so the description should clarify parameters. It implicitly relates accountType to Unified wallet and fromCoinList to a list of up to 20 coins, but does not explain valid values for accountType or toCoin, nor the exact syntax for fromCoinList. This leaves significant ambiguity for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Apply for batch conversion quote for a small asset list.' It specifies that it returns a quote ID and per-coin conversion details, distinguishing it from sibling tools like SmallAssetConvert, which presumably executes the conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit constraints: API key permission (Convert), rate limit (5/s), wallet support (Unified wallet only, eb_convert_uta), max coins per transaction (20), unsupported custody accounts, and balance behavior. While it doesn't explicitly say 'use this before SmallAssetConvert', the context implies it. It lacks explicit 'when not to use' but the constraints serve as guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool modifies real orders via WebSocket, that the response is only an acknowledgment, and recommends verification. It could mention failure cases for already-filled orders, but overall is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a warning, with the purpose front-loaded. Every sentence adds necessary context without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and usage caveats, including verification steps. For a 2-parameter tool without output schema, it is reasonably complete, though it could mention error handling for partially successful cancels.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal value beyond schema descriptions; it reiterates the need to confirm details but does not provide additional parameter nuance. The max limits per market type are already in schema (maxItems:20).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool batches cancel operations for unfilled/partially filled orders via WebSocket on Bybit V5. The verb 'cancel' and resource 'orders' are specific, and the 'WebSocket' differentiates from REST-based siblings like batchCancelOrders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises confirming order details with the user before use and notes that the response is an acknowledgment, directing users to verify order status via subscribeOrder or REST. It provides clear context but does not explicitly compare to alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behavior: response is acknowledgment only, confirmation via WebSocket stream. No annotations exist, so description carries full burden. Does not mention rate limits or auth, but these are typical for a cancel endpoint.
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?
Reasonably concise with bullet points and hints. Some redundancy between agent hint and bullet points, but overall well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: action, required parameters, behavior, and special case (TradFi). Lacks error handling details, but for a simple cancel tool this is sufficient given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning: explains the relationship between orderId and orderLinkId, priority rule, and orderFilter usage. Does not detail category or symbol but provides enough context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels a single open order by orderId or orderLinkId. It differentiates from siblings like batchCancelOrders and cancelAllOrders by specifying 'single open order'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use: cancel a single open order. Includes constraints (must provide orderId or orderLinkId, priority rule, orderFilter for spot) and a TradFi hint for category. Lacks explicit alternatives but siblings imply batch/available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses rate limit (50 req/s), parameter priority, and side effect (quotes become invalid). Without annotations, these are essential. No mention of idempotency or error cases, but sufficient for the tool's simplicity.
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?
Description is clear and front-loaded with purpose, then parameter rule, side effect, rate limit. Slight redundancy in the agent hint repeating earlier content, but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameter usage, side effect, and rate limit. Lacks error handling or response format, but acceptable for a simple cancel operation. Distinguishes sufficiently from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description compensates by explaining the parameter choice, priority rule, and that one must be provided. Adds meaning beyond the schema's empty descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Cancel an active RFQ' with specific verb and resource. It details parameter behavior (rfqId vs rfqLinkId) and side effect (invalidates quotes), distinguishing it from siblings like cancelAllRfqs and cancelQuote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides parameter usage guidance ('You must pass either rfqId or rfqLinkId') and effect on quotes. Does not explicitly compare to cancelAllRfqs, but the context is clear. Implicit guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses FOK behavior (cancelled if not fully filled), async nature (response is ACK, check getPredictionOrderList), and slippage tolerance. However, it does not explicitly describe failure modes or side effects beyond the exchange, though it is implied.
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?
Description is well-structured with headers (Prerequisites, Do NOT call, Phase 1, Response, Agent hint) and front-loaded purpose. Some redundancy exists between the main description and the 'Agent hint' section, but it remains clear and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the ACK response and async verification via getPredictionOrderList. It covers prerequisites, limitations, and the FOK-only constraint. While it lacks explicit error handling details, it is sufficiently complete for a transactional tool with clear steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains size (shares, not USDC), slippage (price tolerance as string), and orderType (1 = FOK only). However, tokenId, eventId, and toTokenCode are not described. Three out of six parameters are given meaningful context, but others are left to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Execute a sell order for prediction outcome tokens' and 'Exchanges token shares for USDC.' It uses specific verb and resource, and distinguishes from siblings by listing prerequisites that involve other prediction tools like getPredictionPositionList and getPredictionOrderEstimate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites with mandatory order: call getPredictionEngineStatus, getPredictionPositionList, getPredictionOrderEstimate first. It also states 'Do NOT call this endpoint without explicit user confirmation.' and clarifies that only orderType=1 (FOK) is supported.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It reveals that wallet balance returns a range value (mapping provided), deposit amounts update every 5 minutes, trading volume covers three business lines, and commission data is for reference only. These disclosures provide important behavioral context, though it does not explicitly state the tool is read-only (implied by 'Query').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a primary sentence followed by bullet-point notes. It front-loads the main action and then details important caveats. While slightly verbose, each note adds value without redundancy, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema or annotations, the description covers essential aspects: what data is returned, permission requirements, update frequency, and interpretation of range values. It lacks explicit return format details, but the described data points give sufficient context for an agent to understand the output scope.
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 only one parameter (uid) with no description, giving 0% schema coverage. The description compensates by explaining that 'uid' is the Master UID of the direct client to query, adding necessary semantic meaning beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Query detailed information for a specified direct client user under the affiliate account', listing specific data fields (VIP level, KYC level, wallet balance range, etc.). It distinguishes itself from sibling tools like getAffiliateUserList by focusing on a single user's details rather than a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: it requires an API Key with 'affiliate' permission bound to a Master UID, and explains that 'uid' refers to the Master UID of the client. While it does not explicitly mention when not to use it or provide direct alternatives, the notes clarify prerequisites and data refresh behavior, giving clear guidance for correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the rate limit (10 req/s) and that values are returned as string numbers, which is useful. However, it does not explicitly state that the tool is read-only or non-destructive, though the query verb implies that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short sentences plus a rate limit line and agent hint. Every sentence adds value, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description is complete. It covers purpose, parameters, return format, rate limit, and usage guidance, enabling correct invocation without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description adds significant meaning: it explains the baseCoin parameter usage, including that omission returns all coins, and provides example values. This compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries option Greeks aggregated by base coin, listing the specific Greeks returned (delta, gamma, vega, theta). It distinguishes from sibling tools like subscribeGreeks, which is a WebSocket subscription for real-time data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage hint ('Use this for options risk management') and explains how to filter by baseCoin with examples (BTC, ETH, SOL). It does not explicitly mention when not to use or alternative tools, but the context is clear enough for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It discloses that it's a private endpoint (auth required), rate limit (5 req/UID), returns empty if no loans, and distinguishes flexible/fixed debt. Missing explicit statement that it is read-only, but implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings (Features, Use Cases, Important) and front-loads the purpose. It is slightly verbose but each section adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers features, use cases, and important notes. It effectively describes what the tool returns (position metrics, breakdowns) but lacks explicit return format details. Still adequate for understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so baseline is 4. The description does not add parameter documentation (none needed). It effectively lists available response fields via features, which compensates somewhat.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Query the user's current crypto loan position with comprehensive details.' It lists specific metrics (LTV, total debt, collateral breakdown), which distinguishes it from related sibling tools like getCryptoLoanCommonAdjustmentHistory or getCryptoLoanCommonCollateralData.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Use cases are explicitly listed (monitor LTV, view debt/collateral, track borrowing, etc.), providing context for when to use the tool. However, it does not explicitly exclude alternatives or mention when not to use it, leaving some ambiguity among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses no parameters, prerequisites (pre-authorization), rate limit (10 req/s), and behavioral traits like empty result meaning DCP is not configured. No contradictions.
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?
Several sentences but each adds value. Slight repetition (e.g., return info mentioned twice) but front-loaded with purpose. Generally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description explains return format (array of product-level configs with status and time window), prerequisites, and empty result meaning. Could be more specific about structure but adequate for a zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no parameters (coverage 100%). Description simply states 'No parameters needed' and adds no semantic info about parameters beyond what schema shows. Baseline 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries DCP configuration and returns status and time window per product type. It uses the specific verb 'Query' and distinguishes from sibling tools like setDcp and subscribeDcp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to check DCP settings' and provides context like 'Only works for accounts that have DCP enabled' and 'Empty result means DCP is not configured.' Lacks explicit exclusions or direct alternatives but is still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses read-only nature, cursor-based pagination, no authentication required, and default baseCoin for options. However, it does not mention error handling for non-expired symbols or rate limits; slightly incomplete but still good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and sections. Information is front-loaded with main purpose. However, 'Supports cursor-based pagination' appears redundant (in both main description and notes). Agent hint partially repeats earlier points. Slight trimming would improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is quite comprehensive: covers purpose, usage distinctions, pagination, auth, and parameter hints. It differentiates from relevant siblings. Missing details on return fields or behavior for invalid inputs, but still sufficient for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains 'category' filters product type, 'baseCoin' defaults to BTC for options, and mentions 'nextPageCursor' for pagination. But 'symbol', 'settleCoin', 'limit', and 'cursor' are not explicitly described; the schema for 'limit' is self-explanatory but other gaps remain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves historical delivery (settlement) prices for expired futures and options contracts. It specifies the resource (historical delivery prices) and verb (retrieve), and lists specific use cases. It also distinguishes from sibling tool getInstrumentsInfo, which handles upcoming delivery dates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use (e.g., look up settlement price of expired contract, analyze historical delivery prices) and when not to use (upcoming delivery dates, with a direct reference to getInstrumentsInfo). Includes agent hint with specific tips for option queries and cursor-based pagination.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that no authentication is required, explains the reverse chronological sorting, and mentions the funding settlement intervals. For a read-only query tool, this is transparent and sufficient. A higher score would require additional details like rate limits or pagination behavior, but these are not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, bullet points, and a hint at the end. It is appropriately sized for the tool's complexity. Some redundancy exists (e.g., 'Use this endpoint' and 'Agent hint' overlap), but overall it is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema, the description covers the essential aspects: purpose, required parameters, time filtering, and alternative tools. It lacks details on return format or error handling, but these are not mandatory for a simple query tool. The description is complete enough for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'category' and 'symbol' as required, and 'startTime' and 'endTime' for time filtering. However, it does not explain the 'limit' parameter or the enum values for 'category'. With schema coverage at 0%, the description should compensate more fully. The provided hints are helpful but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Query historical funding rate records for perpetual contracts.' It specifies the supported products (USDT contract, Inverse contract) and how records are sorted (reverse chronological order). This distinguishes it from sibling tools like getTickers, which provides current funding rate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases: analyze historical trends, calculate funding cost, compare rates. It also gives a clear 'Do not use' directive for current funding rate, directing users to getTickers instead. This provides excellent guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses data format (5-element array), reverse chronological order, supported products, and no authentication required. Lacks rate limits or pagination details, but for a historical query tool, this is sufficient. No contradictions with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with clear sections (purpose, use cases, supported products, data format, exclusions, notes, agent hint). Each sentence adds value; no redundancy. Ideal length for this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers output format (5-element array), ordering, authentication, and product support. No output schema is present, but the description explains the output adequately. Lacks details on parameter semantics and does not mention error cases, but overall complete for a read-only historical data tool.
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%. The description does not explain individual parameters beyond implying symbol and interval are needed. Category, start, end, and limit are not described. This is a significant gap as the description fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries historical index price klines from composite spot prices. It explicitly lists when to use and distinguishes from sibling tools (getMarketKline, getMarkPriceKline, getPremiumIndexPriceKline), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides three concrete use cases (research/backtesting, basis spread comparison, charting) and explicit 'do not use' instructions with alternatives. Agent hint repeats guidance. Highly actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the read-only/historical nature, that each record summarizes total reward per completed position, and the important startTime/endTime constraints: filter by staking period, require 13-digit ms timestamps, and must be provided together. It doesn't mention pagination details, but the core behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and adds focused detail in the agent hint. There is slight redundancy between the opening sentence and the hint, but overall it is compact and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description does well: it covers authentication scope, output semantics, and the non-obvious timestamp pairing requirement. It could still add pagination behavior or clarify all optional parameters, but a competent agent has enough to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description meaningfully compensates for the riskiest parameters: startTime/endTime are clearly defined as staking-period filters with exact timestamp requirements, and stakeCoin/rewardCoin are identified as filter dimensions. current/pageSize are left to be inferred from names and schema defaults, but this is a minor gap.
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?
States a specific verb and resource: 'Returns the authenticated user's completed Launchpool staking positions, summarising total reward earned per position.' It clearly distinguishes itself from siblings like getLaunchpoolUserCurrentStaking and getLaunchpoolUserActivityLog by emphasizing completed/historical staking positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for use: 'AI agent can use this to show a user their past participation' and 'Agent hint: Use this endpoint to retrieve a user's historical Launchpool positions.' It does not explicitly name alternatives or when-not-to-use them, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses calculation formulas, supported products, pagination, and lack of authentication. Does not mention rate limits or error handling, but adequate given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, bullet points, and agent hint. Front-loaded with purpose. Minor redundancy (pagination mentioned twice), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, calculation, parameters, pagination, and authentication. No output schema, but description doesn't need to explain return values. Fairly complete for a data query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description adds significant value. Explains required params (category, symbol, period) with enums, startTime/endTime for time range, and cursor for pagination. Adds context like 'Supported Products' linking category to actual contract types.
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?
Clearly states the tool queries net long/short ratios as a sentiment indicator. Verb 'Query' and resource 'long and short position ratios' are explicit. Distinct from sibling tools focused on other data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Lists specific use cases: measuring sentiment, tracking trend signals, analyzing historical data. Provides agent hint and required parameters. Does not explicitly mention when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral transparency. It accurately describes return types: group tables for group stages and bracket info for knockout stages. It also states the tool is for providing context for betting decisions, implying it is a read-only operation. No contradictions noted.
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 contains some repetition, especially in the agent hints section which essentially restates earlier information. While the structure is logical (purpose, parameter explanation, agent guidance), it could be more streamlined to avoid redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and two parameters, the description adequately explains what the tool returns (standings, match results, group tables, bracket info) and how to use it in conjunction with getPredictionTimelineStages. It provides sufficient context for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description explains the meaning of both parameters: eventType=1 is FIFA_2026, and stageCode must be one of Groups, R32, R16, QF, SF, Final. This fully compensates for schema omissions, adding critical semantic context beyond enum lists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns detailed standings and match results for a specific tournament stage, distinguishing between group tables and bracket info. References associated tool getPredictionTimelineStages for obtaining stageCode, which clarifies its role in the tool ecosystem.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use the tool: to query group standings or knockout results. Specifies valid stageCode values and mentions eventType=1 corresponds to FIFA_2026. However, it does not explicitly mention when not to use this tool or suggest alternative tools, leaving some gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that FOK orders show as FILLED or CANCELLED, and lists filtering parameters with their meanings. It does not mention rate limits or pagination details, but overall adequately describes behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: clear purpose, return details, usage context, parameter list, and agent hints. Every sentence adds value, and it is front-loaded with the main operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description mentions return details (fill status, executed price, fees). It covers all key parameters and usage scenarios. Given 7 parameters and 0 required, this is a complete and helpful description.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 0%, so the description must compensate. It explains the meaning of status (with enum mappings), tokenId, eventId, side, and days (max 90). However, it does not explain pageIndex or limit, leaving some parameter semantics missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the authenticated user's prediction market order history, with a specific verb ('Query') and resource ('prediction market order history'). Among many sibling 'get' tools, this distinguishes itself by focusing on prediction orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this after placing a buy or sell order to check the final execution status,' providing clear when-to-use guidance. It also gives agent hints about filtering. It does not explicitly list alternatives, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses no authentication required, return limits (1000 records, spot: 60), reverse chronological ordering, and symbol requirements per category. Does not mention rate limits or pagination, but otherwise transparent for a read-only public endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (supported products, notes, agent hint). Sentences are efficient, though slightly redundant (agent hint repeats earlier guidance). Still concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists return fields and provides limits, auth status, and product support. Adequately covers what the tool returns and important constraints. Could include example or pagination note, but sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains symbol is required for spot/linear/inverse and that baseCoin defaults to BTC for option. It also mentions limit (up to 1000, spot 60). However, it doesn't explain baseCoin usage beyond default, optionType, or category enums fully. Adds some value but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries recent public trading history for a symbol, listing returned fields (price, size, taker direction, timestamp, sequence number). It distinguishes from siblings like getTickers and getOrderbook by explicitly saying what not to use it for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenarios (inspect trade flow, retrieve trade records, correlate with orderbook) and when-not-to (not for current price, 24h stats, orderbook depth), naming alternatives like getTickers and getOrderbook. Also includes an agent hint reinforcing this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that no authentication is required and notes that response fields vary per category. It also specifies the required parameters for options. However, it does not mention rate limits, pagination, or error behavior, but given the read-only nature, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and a summary section. It front-loads the core purpose and is efficient, though there is minor repetition regarding response fields and option conditions. Overall, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 params, no output schema, many siblings), the description covers purpose, usage guidelines, supported products, and parameter constraints. It lacks details on the 'expDate' parameter and could mention size limits, but it is largely complete for a ticker endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 4 parameters with 0% description coverage. The description adds clarity by listing the categories and explaining that for 'option' either symbol or baseCoin must be provided, which is not evident from the schema alone. However, it does not explain the 'expDate' parameter, leaving some semantics incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb 'Retrieve' and clearly defines the resource as 'latest price snapshot, best bid/ask price, and 24-hour trading statistics across all supported product types.' It lists supported products and distinguishes from sibling tools like getOrderbook and getMarketKline by explicitly stating what not to use this tool for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use scenarios (e.g., 'when you need to: Get the current last traded price...') and includes 'Do not use' instructions with specific alternatives for orderbook depth and historical data. The 'Agent hint' section further reinforces appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly identifies the operation as a query (read-only) and discloses the behavior of empty maxQty indicating infinity. It does not mention rate limits or side effects, but for a read-only query, the transparency covers the key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured with a main line, bullet points, and an agent hint. It is front-loaded with the purpose. Could be slightly more concise, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description provides sufficient context: it explains the return structure (tiers with minQty, maxQty, collateralRatio), the infinity behavior, and the public nature. For a simple query tool with one parameter, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain the single parameter `currency`. It does so by stating that omitting it returns all coins, while passing a value filters for a specific coin. This adds essential meaning beyond the schema's bare type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the UTA loan tiered collateral ratio for spot margin trading. It specifies that it returns tiers for all coins if currency is not specified, and explains the structure of each tier. This distinguishes it from other getter tools, though it could be more explicit about the exact return format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an agent hint explaining that this is a public endpoint and should be used to check collateral value contributions at different holding levels. It does not explicitly state when not to use it or mention alternatives, but given the specificity, the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses return details and constraints (unified account, optional filter), but lacks information on authentication, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with three bullet points, front-loaded with purpose, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query with one optional parameter and no output schema, the description explains return values and constraints sufficiently. Also includes service name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining the 'coin' parameter as optional with default behavior ('if omitted, returns all coins'), adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query coin delta amount details for institutional lending hedge product,' which combines a specific verb and resource, distinguishing it from sibling tools like insLoanProductInfos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: 'Unified account only' and optional coin filter. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses secrets are never returned, automatic filtering of system keys, pagination mechanism, expiration statuses, and required permissions. It covers all key behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and bold headers, front-loading the main purpose. It is slightly lengthy due to detailed expiration tables and filtered keys, but every sentence adds value given no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers authentication, security, pagination, response contents, and use cases. It lacks explicit parameter descriptions but compensates with detailed behavioral notes. Overall, it provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains pagination semantics (default limit=20, Base64 cursor) and implies subuid is the sub-account identifier. However, it does not provide explicit, separate descriptions for each parameter, leaving some inference to the user.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries all API keys of a sub-account with pagination, using the master account's API key. It provides specific verb and resource, distinguishing it from siblings like queryAPIKey.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states only master accounts can call this endpoint and lists use cases (managing sub-account API keys, auditing, etc.). However, it does not explicitly mention when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions business rule restrictions, allowed/disallowed conditions, and an error code, but does not detail authentication requirements or side effects beyond the auto-reinvest flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a main sentence and three bullet-point notes, front-loading the core purpose and efficiently adding critical constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description covers the main behavior and constraints but does not explain the return format or explicitly map autoReinvest values to actions, leaving some 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 coverage is 0%, but the description explains the purpose of autoReinvest and requires category='OnChain'. However, productId and positionId are not described, and the meaning of '0'/'1' for autoReinvest is left implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets or unsets auto-reinvest for fixed-term OnChain positions, distinguishing it from other earn-related tools that handle different order types or position modifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that only OnChain category is supported, flexible-term positions are not supported (with error code 180028), and provides constraints on when enabling/disabling is allowed, covering when to use and when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses authentication requirements, rate limiting per UID, the possibility of partial or full match, LTV requirements, and a prerequisite quote step. These are meaningful behavioral details beyond what the schema exposes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Features, Use Cases, and Important sections, and the leading sentence is immediately informative. There is mild redundancy between 'Fixed-term loans with locked interest rates' and 'Borrow crypto with fixed interest rate', but overall it is efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides a solid operational picture: authentication, rate limits, pre-flight quote check, LTV constraints, and partial-fill behavior. It does not cover every edge case or explain all optional parameters, but it is adequately complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 adds practical meaning to parameters: terms are expressed as day durations (7D, 14D, 30D, etc.), collateral is plural and currency-based, auto-repay is optional, and partial/full matching maps to the strategyType concept. However, repayType and some string-format details are not explicitly explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create a fixed-term borrow order', and enumerates the key inputs (loan currency, amount, rate, term, collateral). This clearly differentiates it from sibling tools such as postCryptoLoanFlexibleBorrow and postCryptoLoanFixedSupply, which concern different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases and context: fixed-rate borrowing for a specific term, multiple collateral currencies, and locking in rates for 7D to 180D. It also advises checking the quote endpoint first and meeting LTV requirements. However, it does not explicitly contrast with flexible borrow or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description goes beyond basic functionality by explaining key behavioral details: the effect of omitting the coin parameter, the meaning of status values ('0' = suspended, '1' = normal), interpretation of 'remainAmount', and the impact of compliance whitelist filtering. This provides useful context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five well-structured sentences with bullet points that front-load the main purpose. Every sentence adds value, no redundancy. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the return structure: all coins if no coin specified, each coin includes chain list with deposit/withdraw status, max withdrawal amount, and compliance filtering. This covers the key elements needed to understand the tool's results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by explaining the semantics of the sole parameter 'coin': when omitted, all coins are returned. This adds meaning beyond the schema's bare type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a clear verb+resource: 'Query coin information' and specifies scope including chain configuration, deposit/withdraw status. It distinguishes itself by detailing that omitting the optional 'coin' parameter returns all supported coins, which differentiates it from possibly more specific coin queries among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for querying coin details but does not explicitly state when to use this tool versus alternatives like 'queryCoinList' or other query tools in the sibling list. No 'when not to use' or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses sorting order (newest first), pagination (cursor, max 50, default 20), time filter format (Unix seconds), and explains status values (2-6). It does not mention destroy effects (none expected) or rate limits, but as a read query it is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections: intro, when to use, query modes, status values, important notes, agent hint. It is front-loaded with purpose. While verbose, every sentence serves a purpose. Minor redundancy in 'Query modes' could be tightened, but it remains clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no output schema, and no annotations, the description covers key aspects: purpose, usage modes, status value meanings, pagination limits, sorting order. It does not describe the response structure or potential errors, but for an agent to select and invoke the tool, the provided context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It explains the four query modes, mapping to parameters: exact lookup (strategyId), filtered list (symbol, category, strategyType, status), time range (beginTimeE0, endTimeE0), paginated (cursor, pageSize). It also details status values. It does not explain category or strategyType enums nor the cursor format, but overall provides substantial semantic enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of strategies with filtering and pagination. It distinguishes from sibling tools like createTwapStrategy or stopStrategy by focusing on querying. The verb 'retrieve' and resource 'strategies' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section lists concrete scenarios (check status, monitor running, review performance, filter by symbol/type/time). The 'Query modes' map to different parameter combinations. An agent hint provides example queries. It lacks explicit when-not-to-use or comparisons with sibling tools like getGridDetail, but it's still strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description clearly indicates this is a read operation (query) and specifies the return type. It also notes the authentication requirement. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the verb and resource. Every sentence adds value—purpose, return data, and constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description sufficiently explains the tool's functionality and return values for a simple query with no parameters. No 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?
No parameters, so schema coverage is 100%. The description adds meaningful context about what the tool returns beyond the empty schema, fulfilling the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it queries sub UIDs under the current master UID, specifies the return data (all sub UIDs and those with universal transfer permission), and notes the API key requirement. This distinguishes it from siblings like querySubMembers or listSubAPIKeysV5.
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 mentions 'Master UID API key only' as a prerequisite, but does not explicitly compare to sibling tools or state when to use this tool over alternatives like querySubMembers or querySubMembersV5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that cancellation is by criteria and that response is acknowledgment only (confirm via WebSocket). However, it does not mention idempotency, rate limits, or potential partial failures. The description adds some behavioral context but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and an agent hint. It is front-loaded with the main purpose. Each sentence adds value, though the text could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema) and many sibling tools, the description covers cancellation criteria, category-specific behavior, and suggests alternative tools. It lacks details on response structure beyond 'acknowledgment' and synchronous vs async behavior, but the WebSocket hint partially addresses confirmation. Overall fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains each parameter: category (required), symbol, baseCoin, settleCoin, orderFilter, stopOrderType. It provides category-specific rules (e.g., must provide at least one symbol/baseCoin/settleCoin for linear/inverse, no filter for options, default for spot). This adds significant meaning beyond the schema enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cancel all open orders matching the specified criteria.' It uses a specific verb (cancel) and resource (all open orders), and distinguishes from the sibling tool 'cancelOrder' for single order cancellation. Different category-specific behaviors are detailed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this endpoint to cancel all open orders for a category/symbol at once.' Provides alternatives: 'For cancelling a single order, use cancelOrder instead.' Includes conditional requirements for linear/inverse and defaults for spot and options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: cancellation of pending orders and position closure, required bot state, and rate limit. It lacks details on error handling or idempotency, but the main actions are clear. The agent can infer what happens upon success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with each sentence serving a purpose. It starts with the main action, then lists effects, prerequisites, rate limit, and an agent hint. No unnecessary 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?
The description covers the action and prerequisites well but does not describe the return value of the tool itself (e.g., success status or error codes). It hints at using getFGridDetail for post-action details, but the immediate output is omitted. Given the simplicity of the tool and lack of output schema, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter bot_id has no description in the schema, but the description explains where to obtain it (from createFGridBot response or getFGridDetail), adding significant value beyond the bare schema. This is a clear and helpful explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it closes a running futures grid trading bot, distinguishing it from sibling tools like closeGridBot (spot grid) and others. The verb 'closes' and resource 'futures grid trading bot' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use (to stop a running bot), preconditions (only running bots), and where to obtain the bot_id. It also suggests follow-up action (use getFGridDetail). However, it does not explicitly mention when not to use or alternatives for spot grid, but the differentiation is implied by the 'futures' qualifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description covers key behavioral aspects: the bot will automatically place orders, validation is required, rate limits apply, and error handling via status_code and check_code is explained. It also implies financial impact by noting KYC/compliance and the need for a bot_id for subsequent operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary action, followed by a clear enumeration of required/optional parameters, preconditions, rate limits, and an agent hint. No redundant sentences; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high complexity (25 params, 0% schema coverage, no output schema), the description covers purpose, usage guidelines, error handling, and follow-up actions. However, it lacks explanations for parameter enums and nested structures, leaving some ambiguity for agents.
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%. While the description lists required and optional parameters by name, it does not explain the meaning or allowed values of enums (e.g., grid_mode, grid_type, tp_sl_type) or provide context for nested objects like toolsDiscoveryParameter. With 25 parameters, this insufficiently aids the agent in selecting correct values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's core function: 'Creates a single futures grid trading bot.' It specifies the automation of grid orders within a price range and distinguishes itself from sibling tools like validateFGridInput (validation), closeFGridBot (closing), and getFGridDetail (inspection).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Before calling this endpoint, use /v5/fgridbot/validate to validate parameter ranges.' It also mentions rate limits (10 req/s per UID), compliance/KYC requirements, and an agent hint to always call validateFGridInput first. This clearly tells the agent when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: returns an acknowledgment only, on-chain confirmation takes 10-60 seconds, and dercRatio meaning. It does not detail error handling or idempotency, but the warning about user approval and tracking via getLPOrderList adds sufficient 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 well-structured: first sentence defines purpose, then prerequisites, warnings, and agent hints. Every sentence adds value, with no redundancy. Front-loaded with crucial info, and uses bold for emphasis. Ideal conciseness for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, minimal schema coverage, and no annotations, the description effectively covers context: prerequisites, post-call tracking, timing, and usage warnings. It lacks explanation of receiveTokenCode and potential errors, but the agent hints and prerequisites fill many gaps. Slightly incomplete but very strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 0%, so description must explain parameters. It explains dercRatio with examples ('0.5' = 50%, '1' = full) but does not describe positionId, poolAddress, or receiveTokenCode. While prerequisites imply positionId/poolAddress come from getLPPositionList, missing explicit definitions reduce clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute LP redemption to withdraw liquidity from a pool position.' It specifies the action (execute LP redemption), the resource (pool position), and distinguishes it from siblings like 'executeLPStake' and 'getLPPositionList'. The return of an order number for tracking further clarifies functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites: call getLPPositionList first, display redemption details to user, and obtain explicit confirmation. It warns against direct calls without approval and directs to use getLPOrderList for tracking. This clearly differentiates when to use vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description discloses key behavioral traits: it is a write operation, requires user confirmation, returns an orderNo acknowledgment, and on-chain confirmation takes 10-60 seconds. It warns about the need for valid quote data, providing sufficient transparency for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bolded sections for prerequisites and warnings, and front-loaded with the core purpose. While most sentences add value, the agent hints section partially duplicates earlier points, making it slightly less concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema), the description covers prerequisites, return value, and tracking via getOrderList. However, the lack of parameter explanations for the majority of inputs leaves a notable gap, preventing a perfect score.
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 description mentions only three parameters (quoteData, correctingCode, gas) in the context of prerequisites, but does not explain the remaining six parameters (fromTokenCode, fromTokenAmount, toTokenCode, slippage, quoteMode, tenant). With 0% schema description coverage, the description should compensate but fails to provide meaning for most 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 tool's purpose: 'Place a buy order to purchase on-chain tokens with payment tokens.' It distinguishes from sibling tools by explicitly mentioning that selling should use executeRedeem instead. The verb+resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites (call getTradeQuote first, get user confirmation) and exclusions (do not use for selling, do not call without valid quote, do not guess parameters). It also directs users to getOrderList for tracking, offering clear guidance on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 discloses that the response is an acknowledgment only and that on-chain confirmation takes 10-60 seconds. It also warns that quoteData, correctingCode, and gas must come from a non-expired getTradeQuote response, covering key behavioral traits beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and clear warnings, and it front-loads the purpose. While it is relatively long, every sentence adds value; minor redundancy exists (e.g., 'obtain explicit user confirmation' repeated), but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 params, 8 required, no output schema), the description covers prerequisites, response behavior, and execution workflow. However, it lacks explanations for individual parameters and does not describe the return value beyond orderNo. While output schema is absent, more parameter detail would improve 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?
Schema description coverage is 0%, so the description must add parameter meaning. It only mentions that quoteData, correctingCode, and gas come from getTradeQuote, but does not explain other required parameters like fromTokenCode, fromTokenAmount, toTokenCode, slippage, quoteMode, or tenant. This is insufficient for a 9-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Place a sell order to redeem on-chain tokens for payment tokens,' clearly stating the verb, resource, and scope. It explicitly distinguishes from buying by saying 'Do NOT use this for buying — use executePurchase instead,' differentiating it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites: must call getTradeQuote first, display quote to user, and obtain explicit user confirmation. It also states when not to use (e.g., without valid quote, without user approval, for buying) and directs to getOrderList for tracking, giving comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations being provided, the description discloses important behavioral traits: quotes are sourced from institutional market makers, update frequently at the second level, are real-time, and require no authentication. It also notes rate limits, giving the agent sufficient context for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, front-loading the main purpose. It efficiently includes the purpose, data source, update frequency, rate limit, and a usage tip without redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description provides adequate context by mentioning the return includes target prices and APY. The rate limit and WebSocket alternative are also helpful. However, more detail on the exact structure of the quote data could improve 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 description does not elaborate on the parameters beyond the schema. With schema description coverage at 0%, the description should compensate, but it only mentions 'specific Dual Assets product', while the category enum includes other product types. This could cause confusion about which categories are valid for this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gets real-time quotes (target prices and APY) for a specific Dual Assets product. This distinguishes it from sibling tools like getAdvanceEarnProduct, which retrieves product details rather than quotes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions that no authentication is required, provides a rate limit of 50 req/s per IP, and advises using WebSocket for real-time updates while using this endpoint for initial load or fallback. This gives clear guidance on when and how to use the tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: permission requirements, pagination behavior, default values, conditional field inclusion/exclusion, and fixed currency in commission map. It even advises on performance overhead, leaving no important ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with the core purpose, then pagination, optional data, and finally clear bulleted notes. Every sentence contributes without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description covers authentication, pagination, parameter interactions, and response behavior comprehensively. It equips an agent with enough detail to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description extensively explains cursor, need30/need365/needDeposit, and date range parameters. Only 'size' is not explicitly described, though the schema provides its constraints. The description adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Query' and the resource 'list of all direct client users under the current affiliate account', making the tool's purpose obvious. However, it does not explicitly differentiate this tool from sibling tools like getAffiliateUserInfo, so a distinction is lacking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for usage: requires affiliate permission, cursor-based pagination details, and conditions for optional parameters. It lacks explicit exclusions or alternative tools but offers strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the response structure (assetList array with 0 or 1 element) and explains the meaning of an empty array (user does not hold or token not available). It does not explicitly state the tool is non-destructive, but the description implies it is a read query. With no annotations, this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and key details. However, there is some redundancy between the description and the agent hint section (e.g., repeating the assetList structure and do-not-use instructions). Could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains the return structure (assetList array, fields returned), the empty case meaning, and points to sibling tools for other needs. It covers all necessary context for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions in schema). The description tells the agent to get chainCode and tokenAddress from getAssetList or getBizTokenList, which adds context, but does not independently define the parameters' meaning or format. This is helpful but insufficient for full semantic clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Query detailed holding information for a specific token by chain code and token address.' It lists specific return fields (quantity, USD value, unrealized PnL, etc.) and explicitly distinguishes it from sibling tools like getBizTokenPriceList and getBizTokenDetails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (agent hint: when user asks about a particular asset), when-not-to-use (do not use for general market data or project info), and alternative tools (getBizTokenPriceList, getBizTokenDetails). Also advises where to obtain the required parameters (getAssetList or getBizTokenList).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does this exceptionally well, covering authentication, parent/sub-account resolution, zero-balance filtering exceptions, valuation currency default, UTA DirectStocks merging, conditional categories breakdown, negative equity handling, and final response filtering. This is far more transparent than most tool descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a single front-loaded purpose sentence followed by compact bulleted notes. Each note conveys a distinct behavioral fact or edge case, and there is no filler, schema repetition, or redundant elaboration. The length is justified by the number of important behaviors disclosed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of both annotations and an output schema, this description is remarkably complete. It covers authentication, account scoping, defaults, filtering rules, special account-type behavior, and what the response will include. An agent has enough context to invoke the tool correctly and interpret the result appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It meaningfully explains memberId as a sub-account selector, states that valuationCurrency defaults to USD, and contextualizes accountType through the zero-balance filtering rule and named account types like UnifiedTradingAccount and FundingAccount. It does not enumerate all possible accountType values or provide formats, which prevents 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 opens with a specific verb and resource: 'Query the total asset overview for the current account, including per-account-type equity breakdowns, category details, and coin-level details.' This clearly states what the tool does and its scope. However, it does not explicitly differentiate this tool from sibling asset-related tools like getAssetList or getAssetDetail, so it is clear but lacks explicit 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: for querying total assets of the current account, including sub-account scenarios via memberId. It even explains authentication requirements and parent/sub-account behavior. However, it never explicitly names alternatives or states when not to use this tool versus another, so it stops short of full exclusions/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully covers behavior: read-only, pagination, date limits, sorting. Clearly states it returns historical data for the current user, no destructive actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs: first states purpose and output fields, second provides agent hint with usage details. Front-loaded and no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains output fields, pagination, date range, sorting, and user scope. Missing details on category enum and symbol, but overall covers essential aspects for a 6-parameter tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It mentions cursor for pagination and date range constraints, adding meaning beyond schema, but does not fully explain parameters like symbol, limit, or category enum. Partial added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it queries closed PnL records for the current user, listing key fields. The verb 'Query' with 'closed PnL' distinguishes it from siblings like getOrderHistory or getTradeHistory, which focus on different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit agent hint to use for historical closed PnL, and specifies constraints: up to 730 days, max 7-day range, sorted newest first, cursor pagination. Lacks alternatives but the guidelines are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses important behaviors: private endpoint (auth required), rate limit of 5 requests per UID per time window, pagination with cursor, before/after LTV, and adjustment status. This is comprehensive, though it could mention error handling for invalid adjustId.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (Features, Use Cases, Query Modes) and is concise, covering key points without unnecessary words. Slightly verbose but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool with 4 optional parameters and no output schema, the description fully explains behavior, query modes, rate limits, and use cases. It is complete and leaves no major gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the tool description explains each parameter's role: adjustId for specific adjustment (no pagination), collateralCurrency for filtering, and limit/cursor for pagination. This adds significant meaning beyond the schema's raw types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries historical collateral adjustment operations with pagination support. It uses a specific verb ('Query') and resource ('collateral adjustment operations'), distinguishing it from sibling tools like getBorrowHistory and getCryptoLoanCommonCollateralData.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (review adjustments, track LTV changes, verify operations, audit) and query modes (by adjustId or currency). It implies when to use this tool for adjustment history but does not explicitly state when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully handles behavioral disclosure. It discloses that the endpoint is public, has a rate limit, supports filtering by currency and VIP level, and covers both flexible and fixed-term loans. It does not describe the response format, but the key behavioral traits are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a short introductory sentence, clearly labeled Features and Use Cases sections, and bullet points. Every sentence adds value, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 optional parameters and no output schema, the description covers usage scenarios, filtering options, and rate limits. It does not explain default behavior when parameters are omitted, but overall it is fairly complete for a simple query tool.
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 2 parameters with 0% schema description coverage, but the tool description adds meaning by explaining that 'currency' allows querying by specific currency or all, and 'vipLevel' filters by VIP level. It does not specify data types or formats, which is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries information about currencies available for borrowing, using a specific verb and resource. It distinguishes from sibling tools like getCryptoLoanCommonCollateralData by focusing on loanable data. The features and use cases further reinforce its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases, such as checking currency availability and viewing interest rates, and mentions that it is a public endpoint. However, it does not explicitly state when not to use this tool or compare with alternatives like other crypto loan query tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Clearly states it 'Retrieves comprehensive details' with no side effects, mentions rate limit, and lists return fields including PnL, position, close reason. Lacks explicit clarification on authentication requirements or error behavior, but overall transparent for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (5-6 sentences) with each sentence adding value (purpose, content list, parameter source, rate limit, agent hint). No redundancy, though could be slightly more compact without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description sufficiently details response contents: configuration, status, PnL metrics, position info, margin balances, timestamps, close reason. Adequate for a single-parameter read tool, but lacks mention of error responses or permission requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter bot_id is undocumented in schema (0% coverage). Description adds crucial context: it is 'a numeric ID obtained from createFGridBot or bot listing endpoints', directly supporting correct parameter usage and value acquisition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Retrieves comprehensive details' and explicitly lists the types of information included (configuration, status, PnL metrics, position info, margin balances, timestamps). It clearly distinguishes this futures grid bot tool from similar sibling tools like getFMartDetail and queryGridDetail by specifying 'futures grid bot' and outlining unique fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides source of bot_id (from createFGridBot or bot listing endpoints), rate limit (10 req/s per UID), and an explicit hint to use this endpoint for checking status/performance, preferring it over others. Does not explicitly state when not to use or mention alternative tools for other actions, but guidance is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: authenticated endpoint, permission requirement, data retention, parameter constraints, and URL encoding for 'No VIP'. Does not describe return format or rate limits, which are minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then provides necessary details. Some redundancy exists between the main text and agent hint, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers auth, parameters, defaults, and constraints. Missing description of return format (since no output schema), but still provides sufficient context for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage; the description fully compensates by detailing each parameter: currency required, startTime/endTime usage and constraints, vipLevel optional with default behavior, and encoding note. Adds substantial meaning.
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 'Query historical borrowing interest rate data for UTA spot margin.' This is a specific verb-resource combination that distinguishes the tool from siblings like getFundingRateHistory or getHistoricalVolatility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly outlines when to use: requires Spot permission, startTime and endTime together, max 30-day window, defaults to last 7 days if omitted, data available up to 6 months. Lacks explicit 'when not to use' or alternatives but provides strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden and mostly succeeds: it reveals that this is a read-style operation ('Returns'), indicates authentication expectations via 'authenticated user's', and discloses response content including USD-denominated totals and per-position fields. It does not explicitly state 'no side effects' or describe empty-result behavior, but the get-style name and 'Returns' language make the read-only intent clear.
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 core information is front-loaded in the first sentence and the description is compact overall. However, the 'AI agent can use this...' and 'Agent hint' paragraphs largely repeat the same usage direction, creating minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description is complete for its zero-parameter read-only purpose: it covers what the endpoint returns, the key fields the agent needs to summarize a portfolio, and the intended user-facing use case. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and a baseline of 4 applies because there are no parameters to document. The description reinforces that the tool acts on the authenticated user's data, which is consistent with the no-parameter design.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Returns the authenticated user's active Launchpool staking positions' and enumerates the exact contents (USD portfolio summary, staked amount, accumulated reward, auto-redeem date). The 'active' qualifier helps distinguish this from history/activity siblings such as getLaunchpoolUserHistory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says the endpoint should be used to show a user their current staking overview/portfolio at a glance, which gives clear usage context. It does not explicitly name alternatives or exclusion cases, but the 'current active positions' framing implies the boundary against historical/activity endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It explains the tool's dual behavior (single vs list), visibility rules for Pending orders, default status filtering, and rate limit. This is comprehensive for a query tool with no destructive actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, uses bullet points for clarity, and every sentence adds value. No fluff or redundant information. Front-loads the main purpose and then details behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema, the description covers both usage modes, filtering defaults, and rate limits. It could elaborate on pagination cursor usage but the mention of 'cursor-based pagination' suffices. Overall sufficiently complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions), but the description compensates by explaining how orderId/orderLinkId change behavior and that other parameters filter the list. It also notes the default status filter. This adds significant meaning beyond the bare parameter names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query Liquidity Mining order history with cursor-based pagination' and 'serves as the single-order detail query'. It specifies the resource (Liquidity Mining orders) and distinguishes from numerous sibling tools by being specific to liquidity mining.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage scenarios: pass orderId/orderLinkId for single order retrieval (with Pending orders visible) or omit for paginated list (Pending excluded). Also mentions default status filter and rate limit. While it doesn't explicitly say when NOT to use this tool, the dual-mode description offers clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists output contents but does not disclose potential side effects, performance, or data freshness. As a read-only query, basic transparency is present but could be improved.
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?
Four sentences with clear structure: purpose, usage context, agent hint, and parameter requirement. No unnecessary words; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only one parameter, the description covers purpose, usage, and parameter source. Lists included information (APY, fees, etc.) giving a sense of output, but lacks return structure details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, and description adds 'poolAddress is required and must come from getLPPoolList,' which specifies the source and necessity of the parameter, adding meaning beyond the schema's type declaration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Query detailed pool information including APY breakdown, fees, token reserves, and historical performance,' using a specific verb and resource. It clearly distinguishes from sibling getLPPoolList by indicating this provides details for a specific pool after selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use this after selecting a pool from the pool list' and 'Call this before staking to show the user complete pool details.' Also states poolAddress must come from getLPPoolList, providing clear context and prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool is a query (read-only) returning real-time position data with specific fields. It mentions supported contract types but does not cover pagination behavior or rate limits. However, since no annotations exist, the description adequately conveys the tool's non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, contract support, and parameter hints. It is front-loaded with the core action, no superfluous words, and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, no output schema), the description covers the main functionality and parameter selection but lacks details on pagination (limit, cursor) and response structure beyond a few fields. It is mostly complete for typical usage.
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% description coverage; the description compensates by explaining how to use category, symbol, settleCoin, and baseCoin for different contract types. It omits explanation for limit and cursor (pagination) but overall adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query real-time position data such as PnL, leverage, liquidation price, and margin info' and specifies contract types (linear, inverse, option). It distinguishes from siblings by focusing on current open positions, unlike order or account info tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this endpoint to check current open positions' and explains parameter selection per contract type (linear/inverse vs options). It does not explicitly mention when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavioral traits: not real-time, sorted by createdAt descending, supports cursor-based pagination, rate limit 50 req/s, priority logic, and parameter invalidity. This adds necessary context for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, uses bullet points and bold for emphasis, and front-loads the main purpose. It is well-structured with separate sections. Minor extra wording like 'Agent hint' slightly reduces conciseness but adds clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 7 parameters, description covers filtering, pagination, sorting, rate limit, and real-time distinction. However, it lacks details on the expected output format or fields returned, which is important for a query tool. Slightly incomplete for an agent to fully understand the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It mentions filtering by IDs, trader type, and status, and explains priority and invalidity. However, it does not describe limit, cursor, or the exact meaning of each parameter in detail. Some parameters like limit and cursor are only implied through pagination mention.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries historical quotes with filtering options, and explicitly contrasts with the real-time endpoint. The verb 'Query' and resource 'historical quotes' are specific, distinguishing it from sibling tools like getQuotesRealtime.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: when to use this tool (historical data) vs Get Quotes Realtime (live data). Also details priority among identifiers (quoteId > quoteLinkId > rfqId) and a constraint (quoteLinkId invalid with traderType 'request').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It covers sorting, parameter interactions, rate limits, and increased latency during volatility. However, it does not specify that it is a read-only operation or the authentication required, but the context implies safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it starts with the main purpose, provides details on behavior and constraints, and ends with a useful agent hint. Every sentence adds value with no redundancy. It is concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the return behavior (non-final RFQs, sorted by createdAt descending) and mentions rate limits and latency. It does not describe the structure of returned RFQs, but for a real-time query tool, this is acceptable. A minor gap exists in not specifying the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 0%, so description must compensate. It explains precedence between rfqId and rfqLinkId, and that rfqLinkId is invalid when traderType is 'quote'. However, it does not define what rfqId or rfqLinkId represent, leaving the agent to infer from naming. This adds some value but is insufficient for full compensation.
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 'Query RFQs in real-time from the RFQ engine' and specifies it returns 'all non-final RFQs sorted in descending order by createdAt'. This provides a specific verb-resource pair and distinguishes it from historical RFQ queries via the agent hint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Use this for real-time RFQ data. For historical data, use Get RFQs (rfq-list) instead.' It also clarifies parameter precedence and invalid combinations (rfqLinkId ignored when traderType is 'quote'), and mentions rate limits and latency conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses rate limit (10 req/s), behavior that exact identifiers override other filters, default time ranges, and a 180-day lookback limit. This provides sufficient behavioral insight for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear sections: purpose statement, rate limit, and notes. Each sentence provides essential information without redundancy. It is well-structured and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so description cannot explain return values. However, it covers behavioral aspects, rate limits, defaults, and edge cases (exact lookup behavior, lookback limit). For a query tool, this is largely complete. Minor missing: pagination cursor behavior is not explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It mentions key parameters (orderId, orderLinkId, orderType, productId, startTime, endTime, limit) and explains their behavior (exact vs paginated, filter overriding, defaults). It adds meaning beyond the bare schema, though not every parameter is detailed.
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 'Query RWA order history' with specific verb 'Query' and resource 'RWA order history'. It distinguishes from sibling tools by focusing on RWA orders, which are separate from general order history tools like getOrderList.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use exact lookup (when orderId or orderLinkId provided) vs paginated listing, and provides default time ranges and lookback limit. It does not explicitly list when NOT to use, but the sibling list contains many order-related tools, and the RWA specificity is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behavioral traits: returns up to 1000 records sorted reverse chronological, no authentication required. Missing details like rate limits or error handling, but for a public read endpoint this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-organized with clear sections: main action, bulleted use cases, negative directives, notes, and agent hint. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, return fields, constraints, and alternatives. Lacks output schema but describes return fields. For a simple query tool, it is nearly complete; could mention pagination or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains the symbol parameter (required, source from getSpreadInstrumentsInfo) and implies limit usage via 'Returns up to 1000 records'. However, it does not explicitly describe the limit parameter's role, default, or range beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with a specific verb ('Query') and resource ('recent public spread trading history'), and includes concrete return fields (price, quantity, taker direction, timestamp, cross sequence number). It explicitly distinguishes from sibling tools by naming getSpreadTickers and getSpreadOrderbook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases ('inspect recent trade flow', 'retrieve trade records for display', 'correlate trades with seq') and clear negative directives ('Do not use for best bid/ask or 24h stats — use getSpreadTickers instead'; 'Do not use for order book depth — use getSpreadOrderbook instead').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It transparently discloses that the tool returns status and buffered messages for all active subscriptions, which is appropriate for a read-only diagnostic 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, consisting of two clear clauses that front-load the action and purpose without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given its simplicity and sibling context, the description adequately covers what the tool does and its purpose. The lack of output schema is compensated by mentioning returned fields (status, buffered messages).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description cannot add meaning beyond the schema. With 0 parameters, baseline is 4, and the description correctly implies no input is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all active subscriptions with status and buffered messages, using the specific verb '列出' (list) and resource 'subscriptions'. This distinguishes it from sibling subscription management tools like startSubscription and stopSubscription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly indicates usage for debugging and monitoring, which is adequate for a simple retrieval tool. It does not elaborate on when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses rate limit, idempotency via orderLinkId, and suggests using Get Order endpoint for tracking. The agent hint warns about the real token subscription. No annotations are provided, but the description carries the burden well, though it does not describe the response format or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and bold headings. It is concise yet comprehensive, with no wasted sentences. The agent hint is prominently placed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of token minting/redemption and the lack of output schema, the description covers the core functionality, idempotency, rate limit, and a safety confirmation. It could explain the post-order flow more, but overall it's sufficiently complete for an agent to 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?
With 0% schema description coverage, the description explains the purpose of orderType, accountType (FlexibleSaving/UNIFIED), and orderLinkId (idempotency). It implicitly covers coin and amount, but lacks format details for amount. Adds significant value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it places a Mint or Redeem order for BYUSDT Token, with specific explanations of each operation. It distinguishes itself from sibling tools like createOrder by focusing on token minting/redemption.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use Mint vs Redeem, and includes an important agent hint about requiring user confirmation. However, it lacks explicit comparison to alternative tools like placeEarnOrder or createOrder, which would help in deciding when to use this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses that the endpoint is private (requires authentication), has a rate limit of 5 per time window, considers VIP level and existing borrowed amounts, and returns 0 if insufficient. This is good behavioral transparency for a mutation-like calculation 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?
Well-structured with sections (Features, Use Cases, Important). Every sentence adds value, no redundancy. Front-loaded with the core purpose. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers auth, rate limit, return values (currency amount and USD notional), and edge case (returns 0). Although no output schema, the return format is mentioned. It is complete enough for an agent to make an informed decision.
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?
While schema coverage is 0%, the description explains that 'currency' is the loan currency and 'collateralList' is a list of collateral items with currency and amount. Features and use cases reinforce that the collateral list affects the max loan calculation, adding meaning beyond the property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool calculates the maximum borrowable amount for a specific currency based on provided collateral. It distinguishes from siblings like getCryptoLoanCommonMaxCollateralAmount by focusing on loan amount rather than collateral.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases such as checking borrowing capacity before creating a loan order and validating collateral sufficiency. Does not explicitly mention when not to use or alternatives, but the use cases are clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses rate limit (20 req/s per UID per path), maximum returned strategies (18, 6 for Copy Trading), and that strategies are mixed across bot types. With no annotations, the description carries full burden; it could mention read-only nature, but overall sufficient.
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?
Concise at ~5 sentences, front-loaded with purpose, and each sentence adds value (purpose, composition, rate limit, usage hint). No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, output characteristics, rate limit, and usage context. Lacks explicit statement about read-only nature, but given no output schema and simple parameterless design, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (no parameters), and description explicitly states 'The request takes no parameters,' adding meaning. It also explains the output (biz_type field), surpassing the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a curated list of Aurora AI strategy recommendations for the home feed, mentioning mixed bot types and referencing the biz_type field. This distinguishes it from siblings like recAuroraCreationAIParams (which likely deals with creation) and recExploreStrategy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit agent hint: 'Use this when a user opens the trading-bot home page and wants to see what Aurora is currently recommending.' It also gives next steps (pass aurora_id to info endpoint). However, it does not specify when not to use this tool or contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns up to 6 strategies, has a rate limit, and spans multiple symbols. It does not mention authentication requirements or side effects, but given it's a read operation with a safe profile, the disclosure is adequate for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, well-structured paragraphs. The first explains the core function, the second provides rate limit and an agent hint. Every sentence adds value, and there is no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 param, no output schema) and the description covers purpose, usage, rate limit, and an alternative. It does not explain the biz_type enum values or mention return format, but given the tool's intended context (populating an explore page), the description is sufficiently complete for agent use. Minor gap in enum documentation prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter, biz_type, with enum values '0'-'8' but no description in the schema. The description says 'for a given biz_type' and the agent hint clarifies it's a bot type, but it does not define what each enum value means. With 0% schema description coverage, the description adds some context but leaves the agent to infer the mapping, which could lead to incorrect selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns up to 6 Aurora-recommended strategies for a given biz_type, spanning multiple symbols. It explicitly explains the use case: populating the explore page where users browse by bot type without first picking a symbol, which distinguishes it from similar tools like recAuroraCreationAIParams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this when the user wants to browse Aurora's picks for a specific bot type... without committing to a symbol. To narrow down by symbol once chosen, switch to `/v5/aurora/creation`.' It also includes a rate limit of 20 requests per second per UID per path, giving concrete usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool renews an existing loan, committing to a new term and interest rate, and that it requires unified account access. The agent hint about user confirmation adds transparency about the binding nature. Missing are details on reversibility or failure modes, but overall good.
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 very concise: a single sentence for purpose, bullet points for rules, and a hint. Every sentence adds value without redundancy. It is front-loaded with the action, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description covers the essential conditions and user confirmation requirement. It also includes service name. It is complete enough for an agent to execute with caution, but could be improved by mentioning error cases or what happens if conditions are not met.
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% description coverage, so the description must compensate. It adds meaning to the 'qty' parameter by explaining that if not provided, the full prepayment amount is used, and it conditions the 'loanId' on having allowApplyAmount. However, it does not specify units or format, which would be helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Renew' and the resource 'existing fixed-rate borrow contract', making the purpose unambiguous. It distinguishes itself from siblings by specifying 'fixed-rate borrow contract', which is a specific type among many loan-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit rules for when to use the tool, such as the contract having prepayment amount available and the renewal amount must be greater than 0. It also includes an agent hint about user confirmation. However, it does not explicitly state when not to use or mention alternative tools, so it lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that setting to current value causes an error and explains the equality constraint between buyLeverage and sellLeverage depending on margin mode. However, it does not describe potential side effects like impact on existing orders or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with no wasted words. It starts with the core purpose, then conditions, then an agent hint in a logical order. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 required parameters, one enum, and no output schema, the description covers the main behavior and constraints well. However, it does not mention what the response looks like (e.g., success indication) or any prerequisites like having the contract already, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains the role of buyLeverage and sellLeverage and their constraints, but does not specify the expected format (e.g., numeric string, decimal places) for leverage values, leaving ambiguity.
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 'Set the leverage for a contract position' and specifies supported contract types (linear and inverse), providing a specific verb and resource that distinguishes it from sibling tools like setMarginMode or setHedgingMode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance with mode-specific rules (one-way/cross vs isolated hedge) and a direct agent hint explaining how to use both parameters correctly and warning against setting leverage to the current value, which would cause an error.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the rate limit (5 req/s), that it returns failure reasons, and that portfolio margin has a minimum equity requirement. It could mention idempotency or effects on existing positions, but the provided info is solid.
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 very concise with four sentences covering purpose, parameters, rate limit, and hints. No wasted words; everything is front-loaded and relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers all key aspects: what it does, what modes are available, rate limit, failure handling, and prerequisites (portfolio min equity). It is complete 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 single parameter setMarginMode is well-covered by the schema (enum with three options). However, the description only repeats that it's required and does not add any additional meaning about what each mode implies (e.g., risk profiles, eligibility). With 0% schema description coverage, the description should compensate, but it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the account margin mode and lists the three supported modes (ISOLATED_MARGIN, REGULAR_MARGIN, PORTFOLIO_MARGIN). It distinguishes itself from sibling tools like setLeverage and setHedgingMode by focusing specifically on margin mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('to change the account's margin mode') and provides actionable hints: check result.reasons for failures, note portfolio margin requires equity threshold, and suggests calling getAccountInfo first to check current mode. This covers both when and when-not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the async nature, required API key permission ('Convert'), rate limit (5/s), and load balancing strategy (consistent hash). This goes beyond basic purpose and helps agents understand operational constraints and post-invocation expectations.
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 very concise: one sentence for the core action, followed by three bullet points for async behavior, permission, rate limit, and load balancing. Every sentence adds value without redundancy, making it easy for an agent to parse key information quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the tool's lifecycle well: input (quoteId from get-quote), async execution, and post-invocation action (check Get Exchange History). It also provides permission and rate limit context. Minor omission: no indication of immediate response structure or common failure modes, but acceptable for a tool with one parameter.
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 sole parameter 'quoteId' has no schema description (0% coverage), but the description adds significant meaning by specifying it must come from the get-quote interface. This provenance guidance compensates for the schema gap and helps agents correctly source the value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool confirms and executes small asset conversion using a quoteId from the get-quote interface. This verb+resource combination is specific and distinguishes it from sibling tools like SmallAssetQuote (which generates quotes) and ConvertExecute (likely a general conversion tool). The async nature and status check instruction add precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs users to obtain a quoteId from the get-quote interface and to check final status via the Get Exchange History endpoint. This provides clear context on when to use and what to do after invocation. It does not explicitly mention when not to use or list alternatives, but the workflow implication is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that closing releases resources and makes the ID unusable. Lacks mention of idempotency or error behavior, but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words, front-loaded with the essential action. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is adequate. It covers purpose, side effects, and ID reuse constraint. Could mention potential errors or if calling on already closed subscription is safe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by specifying the origin of the subscription ID (from startSubscription), which enhances understanding beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (close subscription), resource (subscription), and additional effects (release WebSocket connection and buffer, ID not reusable). It effectively distinguishes from sibling subscription tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying the subscription ID comes from startSubscription, but does not explicitly state when not to use or provide alternatives. It gives sufficient guidance for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly identifies this as a read-only query with no side effects. With no annotations, it adequately covers behavioral traits (constraints, no mutation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a query tool with no output schema, the description covers purpose, parameters, and constraints. It does not mention return format or error conditions, but is sufficient for basic usage.
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 to both parameters by naming them and stating constraints (cannot be same, must be supported). Schema has 0% description coverage, so description compensates well, though possible values or examples are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Query' and the resource 'list of coins that can be transferred between specified account types'. The constraints differentiate it from sibling tools like CoinListQuery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit constraints (account types cannot be the same, must be supported) but does not mention when to use this over other query tools like interTransferListQuery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses return of updated position details including liqPrice, constraints on decimal places, and hedge mode requirement. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences plus agent hint, front-loaded with action and mode, efficient and no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: purpose, parameter usage, return value, and constraints. Complete for a margin adjustment tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema coverage, description adds significant meaning: sign convention for margin, decimal limit, hedge mode for positionIdx, and example values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds or reduces margin for a position in isolated margin mode. It distinguishes from the sibling 'addMargin' by explicitly including both add and reduce operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear instructions on using positive/negative values, decimal places, and hedge mode. Does not explicitly mention when not to use or alternative tools, but agent hint gives practical context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: mutation of orders, per-order status checking via retExtInfo.list[].code, that the response is only an acknowledgment and not confirmation (use WebSocket stream), and constraints on order state. This fully compensates for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a clear bullet list with an agent hint section, front-loaded with the main action. Each sentence adds value, though the TradFi hint could be condensed. Overall well-structured and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex batch modification tool with no output schema, the description covers purpose, constraints, per-order status, and verification method. It addresses alternatives and use cases. Lacks some details on error handling or response structure beyond acknowledgment, but is sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains that each item in the request array requires symbol and either orderId or orderLinkId, and mentions category values for TradFi. However, many fields in the request object (e.g., qty, price, triggerPrice) are not explained. The description adds some value but is not exhaustive for all 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 tool modifies multiple existing open orders in a single call, specifies the verb 'modify' and the resource 'multiple orders', and distinguishes from sibling tools like the single-order amendOrder via the agent hint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidelines include using this endpoint for multiple orders vs amendOrder for single orders, max order limits per request (20 for futures/options, 10 for spot), prerequisites like orderId/orderLinkId, and condition that only unfilled/partially filled orders can be amended. TradFi guidance for category usage is also provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the mutation (cancels orders, closes position), rate limit (10 requests per second), and suggests follow-up action (check getFMartDetail for final PnL). This is strong behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded with the core purpose. Each sentence adds value without redundancy, achieving high information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers purpose, prerequisites, rate limit, parameter sourcing, and a recommended follow-up. This is complete for a stop tool, leaving no critical gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the schema: it explains the source of bot_id (createFMartBot or getFMartDetail) and the purpose of stop_type (indicates reason for closing). With 0% schema coverage, this description compensates well, though enum values remain self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool closes/stops a futures Martingale trading bot, specifying the actions: cancel pending orders and close the position. This distinguishes it from sibling tools like closeDCABot, closeFGridBot, etc., which target different bot types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that only bots in a running state can be closed, providing a key precondition. It also offers an agent hint on when to use it. However, it does not explicitly mention when not to use or list alternative tools, though context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains auto-resolution of UTA account, symbol scope derivation, downstream flow, and lists common failure modes. Lacks mentions of idempotency or rate limits, but provides good insight into internal 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?
Well-structured with clear sections: purpose, failures, agent hint. The hint is verbose but valuable. Could be slightly trimmed without losing meaning, but overall every sentence contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 simple parameters, no output schema, and presence of many sibling tools, this description is thorough: covers inputs, behavior, failures, success response format, and follow-up link. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides only types and names with 0% coverage. The description compensates fully by explaining leaderMark as target leader's mark and investmentE8 as integer e8 string with USDT amount example. Also clarifies auto-resolution of UTA account, so no param needed.
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 creates a Copy Trading Classic follow binding with specified leaderMark and investmentE8. It distinguishes from siblings by naming 'Classic' and hinting at a separate MT5 bind tool, but does not explicitly differentiate from createCopyMt5Bind.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use (only after obtaining exact leaderMark), when not to (do not infer from nickname), and detailed agent workflow including leaderboard calls, candidate comparison, and success message format. This is comprehensive and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it lists all returned data categories, mentions rate limit (10 req/s), and notes that close reason is included if stopped. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with key info first (output fields), then bot_id source, rate limit, and agent hint. It is informative but slightly lengthy; could be tightened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides a detailed list of return fields (PnL, margin, position info, etc.) and explains when close reason appears. It is thorough for a read tool, though missing error handling details.
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 one parameter (bot_id) with no description, but the description adds critical context: that bot_id is a numeric ID from createComboBot or listing endpoints. This compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves comprehensive details for a specific futures combo bot, enumerating configuration, PnL, margin, and timestamps. It distinguishes itself from siblings like closeComboBot by focusing on status checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit agent hint to use this endpoint for checking status and performance, and advises to prefer it over other endpoints for performance questions. It lacks an explicit 'when not to use' but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains that the endpoint returns a ranked list and that the order must be preserved. It also mentions return metrics (30-day return, drawdown, Sharpe) used for comparison. While it lacks explicit safety or auth notes, it gives sufficient behavioral context for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long and includes extensive agent instructions that go beyond the tool's own behavior. While the first sentence is front-loaded, the subsequent paragraphs could be more concise. Every sentence is useful, but the length reduces scannability for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully documents the return value: a ranked list with metrics (return, drawdown, Sharpe) and the leaderMark identifier. It also explains the intended use in a conversational flow, making it complete for an AI agent to invoke and process the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is fully covered by definition. The description does not need to add parameter information. It appropriately focuses on the return value and usage. Baseline score of 4 applies as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a curated Copy Trading Classic leaderboard for conversational recommendation flows. It specifies the output is a ranked list of candidate leaders and distinguishes from the sibling getCopyTradingTradFiLeaderboard by name and usage context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit instructions on when to use this tool (in conjunction with the TradFi leaderboard for user queries about reliable copy traders), how to present the two lists separately, and how to map selections to subsequent actions. It also tells the agent not to ask the user to repeat the leaderMark, offering clear when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that no authentication is required, productType=contract is the only supported value, and returns a list of fee groups. Though no annotations are provided, the description covers key behavioral traits for a read query, missing only potential error conditions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, use cases, notes, agent hint). The agent hint is slightly redundant but not excessive. Overall concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes what is returned ('list of fee groups, each with their symbol list and fee rate table'). It also covers supported product type, optional groupId, and authentication status, which is sufficient for this simple query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains productType is required with only 'contract' supported, and groupId is an optional filter (1–8). This adds necessary context beyond the schema's enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Query the tiered fee structure for Pro-level and Market Maker clients, organized by symbol groups,' identifying the exact resource and action. It also distinguishes from sibling tools by noting that standard account fee rates are handled by getFeeRate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists use cases (look up fee rates, understand symbol groups, compare rates) and provides an alternative: 'For standard account fee rates, use the Account getFeeRate endpoint instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the rate limit (10 req/s), the return format (decimal strings), and filtering behavior. However, it does not explicitly state idempotency or side effects; the term 'query' implies read-only but could be more explicit.
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 moderately concise, with a main sentence, filtering details, rate limit, and agent hint. It could be slightly shorter without losing clarity, but the structure is logical and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers purpose, parameters, return format, rate limit, and usage hints. It is complete for a simple query tool. Minor omission: error conditions or empty results not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the required category parameter, the filtering logic for symbol (spot/linear/inverse) and baseCoin (options only), and the return format. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'query' and the resource 'maker and taker fee rates for the specified product category'. It distinguishes from sibling tools by specifying its scope (fee rates) and filtering options (symbol, baseCoin).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to check fee rates before trading', explains when to use symbol vs baseCoin, and states that category is required. It also includes a rate limit hint, providing comprehensive usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full disclosure responsibility. It includes a significant behavioral trait: 'Rate limit: 10 requests per second per UID'. It also describes the response contents (PnL, position, round progress, close reason) which informs the agent about output structure. However, it does not explicitly state that the operation is read-only or idempotent, but the verb 'Retrieves' implicitly conveys a safe read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it opens with the main purpose and a bullet-like list of returned information, then covers bot_id source, rate limit, and an agent hint. While not ultra-concise, every sentence adds value and information is front-loaded. The length is justified by the amount of useful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides a thorough overview of return categories (configuration, status, PnL, position info, round progress, margin, timestamps). It also hints at a close reason when stopped. Missing are exact field names or structure, but the description is sufficient for an agent to understand what data is available. The rate limit and bot_id source further complete the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (bot_id) with no description, but the description adds crucial context: 'The bot_id is a numeric ID obtained from createFMartBot or bot listing endpoints'. This tells the agent where the value comes from, which is beyond the schema's type-only information. For a single parameter with 0% schema coverage, this compensation is effective, earning a high score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb 'Retrieves comprehensive details' and specifies the resource 'futures Martingale bot'. It lists the categories of information (configuration, PnL, position, rounds) and explicitly distinguishes from siblings by stating 'Prefer this over other endpoints when answering questions about a specific bot's performance'. This provides a precise and differentiated purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use this endpoint to check the status and performance of a Martingale bot' and explains how to obtain the bot_id ('from createFMartBot or bot listing endpoints'). It also advises preferring this endpoint over others for bot performance questions, offering clear when-to-use direction relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly discloses behavior: it is a read-only validation endpoint, returns ranges and check_code, and mentions rate limit. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. Rate limit detail could be in annotations but is acceptable here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers usage context, response behavior, and rate limits. Lacks explicit success/error response structure but is adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists most parameters but provides no detailed semantics for each. With 0% schema parameter descriptions, the listing adds some context but not enough to fully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates input parameters for creating a futures Martingale bot and returns allowable ranges. This distinguishes it from siblings like createFMartBot and closeFMartBot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to call this endpoint before creating a bot, and describes the check_code mechanism for validation errors. Provides agent hint and rate limit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fully covers behavior: returns paginated orders with status, amounts, fees, execution time, does not accept orderNo input but response includes it, and clarifies polling 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?
Well-structured with clear sections, front-loaded with purpose, and each sentence adds value. Slightly wordy but not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 7 parameters, the description provides good context: purpose, usage pattern, expected response fields. Could include more param details but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description mentions 'optional filters' and specific filter usage (orderType, orderStatus) but does not explain all 7 parameters (e.g., tokenCode, days, limit, pageIndex, poolAddress). Partially compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries LP order history (stake and redeem) with optional filters, and explicitly distinguishes from sibling getLPPositionList for position details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: call after executing stake/redeem, poll with orderStatus filter, do not use for positions. Includes agent hint with specific match by orderNo.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It conveys that the tool is a read operation returning current user positions with real-time valuation, and implies it is safe for polling. Lacks explicit mention of auth requirements or rate limits, but these are standard for user-specific queries.
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?
Description is clear and front-loaded with purpose and returns. Some redundancy exists between the second paragraph and the agent hint, but overall length is reasonable and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description sufficiently covers tool behavior and usage. Lists specific return fields, provides use cases, and excludes needing to describe return format in more detail. Could mention pagination or error conditions, but not critical for a simple list query.
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?
No parameters exist (schema is empty, coverage 100%). Description adds no parameter info because none are needed. Baseline score of 4 is appropriate as there is no gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the user's liquidity pool positions with real-time valuation and lists specific return fields (staked amount, current value, etc.). It distinguishes from siblings by explicitly warning not to use for pool information, directing to getLPPoolInfo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use: showing LP portfolio or after stake/redeem to confirm. Includes a clear 'Do NOT' instruction with alternative tool name (getLPPoolInfo). No additional context needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behaviors: level limits per product (derivatives 500, spot 200, option 25), sorting order, and no authentication. However, it does not describe the exact response structure or any potential delays, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with sections and bullet points, but slightly verbose (e.g., 'Agent hint' repeats earlier info). Still, it's easy to scan and front-loaded with key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description covers purpose, usage, parameter guidance, and behavioral constraints well. Missing details on the exact response fields, but overall sufficient for an informed tool selection.
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 3 parameters with 0% coverage, but the description adds significant meaning for 'limit' (use=1 for best bid/ask) and 'category' by listing supported products. 'Symbol' is minimally explained, so some gap remains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves orderbook depth data for a trading pair, returning bids and asks. It specifies support for multiple product types, distinguishing it from siblings like getRpiOrderbook and getTickers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists use cases (e.g., inspecting depth before order, best bid/ask) and provides strong when-not-to-use guidance, naming alternative tools (getRpiOrderbook, getTickers). This helps an agent decide between similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature, no auth required, supported products, and return fields. Lacks details on rate limits or data freshness, but sufficient given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and notes, front-loaded purpose. Slight redundancy between initial list and agent hint, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return values, supported products, authentication, and use cases. Could add more on error conditions or data freshness, but adequate for a simple retrieval tool.
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?
With 0% schema description coverage, the description adds meaning by specifying default for category and requiring symbol, despite not elongating enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves allowable price range for order placement, specifies return fields (buyLmt, sellLmt), and distinguishes from sibling getInstrumentsInfo for tick size/precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenarios (validating limit order price, avoiding rejection) and when-not-to-use (tick size/precision), with alternative named (getInstrumentsInfo). Also notes no authentication required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses stricter rate limits (2 req/s) and two modes of operation. While no annotations exist, the description adequately covers behavioral traits for a read-only historical query, though it doesn't explicitly state it's idempotent or read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections for purpose, modes, interval, fidelity, and rate limits. No redundant sentences, but slightly lengthy for a simple query tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage modes, parameters, rate limits, and hints for agents. However, without an output schema, it lacks details on the return format (e.g., fields like timestamp, open, close). Still sufficient for a chart tool.
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?
With 0% schema description coverage, the description adds meaning by explaining interval enum values, fidelity's auto mode, and the two modes (tokenIds vs eventId) including the 20-token limit. It doesn't detail each parameter's type or constraints but provides sufficient context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries historical price data for prediction outcome tokens, returns time series for chart display, and distinguishes from the sibling tool getPredictionTokenPrice for current prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use (getting price chart history) and when not (for current prices, use getPredictionTokenPrice). Provides recommended intervals for daily vs weekly views and suggests preferring tokenIds when known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: returns non-final quotes sorted descending, rate limit of 50 req/s, potential latency during volatility, and detailed parameter priority rules.
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 mostly concise but slightly repetitive (priority order appears twice). However, it is well-structured with clear sections and front-loaded key information. Could be tightened by removing redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers purpose, behavior, limitations, rate limit, and usage hints. It lacks details on what happens when no parameters are provided (e.g., returns all non-final quotes) and pagination, but it is adequate for a real-time query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds some meaning through priority order and the quoteLinkId condition, but it does not explain the purpose of each parameter (e.g., rfqId, quoteId, traderType). The agent must infer that these are filters, but more explicit semantics would be beneficial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries real-time quotes from the RFQ engine, returning non-final quotes sorted by createdAt. It distinguishes itself from the historical Get Quotes tool, as noted in the agent hint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: use for real-time data, for historical use Get Quotes. Priority order and condition on quoteLinkId are explained, helping the agent decide when to use this tool and which parameters to prioritize.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It reveals rate limit (50 req/s) and that the operation is read-only. It does not detail authentication needs beyond 'authenticated account' or error handling, but it sufficiently discloses safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with purpose. The tip and agent hint add value but are slightly redundant. Could be trimmed, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description sufficiently covers purpose, usage timing, and rate limit. It does not describe output format, but that is mitigated by the clarity of purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage. The description adds no parameter details, which is acceptable as there are none. Baseline of 4 is appropriate for no-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it retrieves the RFQ configuration for the authenticated account and lists included items (counterparties, strategy types, maximum legs, minimum order quantities). This clearly distinguishes it from sibling tools like getRfqs or createRfq.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Call this endpoint before creating an RFQ' and includes a tip and agent hint reinforcing when to use. It also tells the agent to call it first to discover necessary data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return type (integer smpGroup), meaning of 0, and rate limit (10 req/s). No annotations exist, so description covers key behavioral aspects. Could explicitly state it's read-only.
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?
Four concise sentences, front-loaded purpose, includes rate limit and agent hint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description explains return value and usage. Covers all necessary context for a simple read-only query.
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?
Input schema has zero parameters; description confirms 'No parameters needed.' Adds clarity beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool queries the SMP group ID and returns 0 if none. It uses a specific verb and resource, and is distinct from siblings like getAccountInfo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to check the SMP group assignment' and notes no parameters needed. Does not mention when not to use or alternatives, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: returns only 'New or PartiallyFilled' orders, supports cursor-based pagination (max 50), may experience latency during high volatility, and is a GET endpoint requiring auth. Adequate transparency for a read query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured with sections (Usage Scenarios, Important, Agent hint). Bullet points enhance readability. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description covers purpose, parameter usage, pagination behavior, and latency. Lacks detail on return format, but overall complete for a read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining the purpose of each parameter: filter by symbol/baseCoin, look up by orderId/orderLinkId, paginate with cursor, limit results. Adds significant meaning beyond the schema's type/constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries 'real-time open spread trading orders'. It uses specific verbs ('Query') and resources ('open spread trading orders'), and distinguishes from siblings like 'getSpreadOrderHistory' by focusing on current 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage scenarios (monitor all, filter by symbol/baseCoin, look up by ID, paginate) and notes all parameters are optional. Mentions authentication requirement. Could be more explicit about when not to use (e.g., for historical orders), but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: max 7-day window, self-trade behavior (both maker/taker), deprecation of execFee for spot legs, and nested leg array. With no annotations, the description fully carries the transparency burden and excels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with headers, bullet points, and a summary. Slightly verbose, but every sentence adds value. Could be trimmed slightly for conciseness, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description covers time range, self-trade, fee fields, and authentication hint. Missing explicit pagination details for cursor/limit, but hinted via 'nested legs array' and 'max 50'. Adequate for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description compensates by explaining time range logic for startTime/endTime, default behavior, and constraints. It does not detail symbol, orderId, orderLinkId, limit, or cursor semantics, but the time range explanation adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query spread trading execution (trade) history, including individual leg execution details.' It uses a specific verb ('query'), identifies the resource ('spread trading execution history'), and distinguishes from sibling tools like getSpreadOrderHistory by focusing on executions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage scenarios (review fills, audit fees, reconcile data), time range logic, and important notes (self-trade, fee handling). It does not explicitly state when not to use, but the context is clear enough with the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the returned list depends on the user's compliance zone (determined by UID), which is key behavioral context beyond the schema. No annotations were provided, so the description carries this burden well. Does not mention rate limits or auth, but for a read-only query that is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with three bullet points. Each sentence adds value: purpose, use case, behavioral note, and a practical hint. No wasted words. Front-loaded with the main verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters or output schema, the description is complete. It explains the tool's purpose, when to use it, a key behavioral aspect (zone-dependence), and a specific usage hint. Nothing essential is missing for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the baseline is 4. Description does not need to add parameter details. It efficiently conveys the tool's function without needing to explain inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool queries the list of available VASPs, specifies the use case (Travel Rule compliance for withdrawals), and adds context about compliance zone. This distinguishes it from sibling tools which are mostly about trading and account management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (for Travel Rule compliance when withdrawing to exchanges) and provides a hint about using 'others' as vaspEntityId. However, does not explicitly state when not to use or mention alternatives, but no direct alternatives exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: pagination, supported filters, conditional parameter requirements, and a privacy layer that removes uid and pan6 before returning data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose. It could be slightly more concise, but every sentence adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and no annotations, the description covers purpose, permissions, conditional logic, privacy, and agent hints. It is quite complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description explains many parameters (statusCode, pan4, merchName, type, txnId, orderNo, time range) and the conditional requirement. Not all parameters are covered, but it adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query Bybit Card asset (transaction) records' with a specific verb and resource. It distinguishes from sibling tools like queryTradeHistory by focusing on card transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies required permissions ('Card read permission') and a conditional requirement for the 'type' parameter. It also provides an agent hint about using pan4 and not asking for uid/pan6, but lacks explicit comparison to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: returns all sub-accounts in single response (no pagination), includes UTA status, account mode determination logic, and detailed process flow. This provides complete transparency about what the tool does and its internal logic.
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 well-structured with sections and bullet points, but it is verbose, including detailed implementation steps (process flow) that may not be necessary for an agent. It could be more concise by focusing on input/output and key constraints rather than internal query logic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (multiple sub-account types, UTA mode logic, and no output schema), the description is very complete. It explains return fields, account types, statuses, modes, and differences from V5, covering all necessary information for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty). Per the guidelines, baseline for 0 parameters is 4. The description adds value by explaining the context of the operation but does not need to document parameters. It covers the purpose well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a complete list of all sub-accounts under the master account, with specific verb 'Get' and resource 'sub-accounts'. It distinguishes from sibling tool querySubMembersV5 by noting the V5 uses cursor-based pagination, and explicitly identifies itself as V3, thus avoiding confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states only master account can call, sub-accounts cannot, and lists use cases. However, it does not explicitly state when to avoid this tool (e.g., for large accounts that might benefit from pagination), though it mentions the V5 alternative. Slight room for improvement in exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully covers behavioral traits. It details the sequence: strategy status becomes 'Terminated,' all pending orders canceled immediately, partially filled orders canceled, filled orders unchanged, and execution stats preserved. It also mentions that terminateType is set to 'UserStop' and that all child orders are canceled. A rate limit of 10 requests/second is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: introduction, when-to-use, step-by-step outcome, important notes, and agent hint. Every sentence adds value, and the length is appropriate for the detail needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description thoroughly explains the effect, side effects (orders canceled, stats preserved), and practical usage (agent hint, common requests). It covers all necessary context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, so the description compensates. It states that the required parameter is strategyId and provides guidance: 'Requires strategyId - if not provided, query strategy list first.' This adds meaning beyond the schema's bare type declaration.
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 'Terminates an active strategy and cancels all associated pending orders.' It specifies the action and the resource, and distinguishes stopStrategy from sibling tools like closeComboBot or createTwapStrategy by focusing on strategies and their termination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' section lists explicit scenarios such as stopping before completion, reacting to market changes, or emergency risk management. It also notes that stopped strategies cannot be restarted and that to continue one must create a new strategy, providing good usage context. However, it does not explicitly contrast with alternatives like closeGridBot or closeDCABot.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return type (array of results with status per quote) and rate limit. No annotations provided, so description carries full burden. Adequately discloses behavior without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, two paragraphs with clear structure. Includes purpose, return type, rate limit, and agent hint. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Full coverage for a simple tool: describes action, return format, and rate limit. No output schema, but return type is adequately explained. Meets all needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, schema coverage 100%. Description adds value by stating 'no request body parameters needed', confirming the empty schema and clarifying usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it cancels all active quotes for the authenticated account. Distinguishes from sibling cancelQuote (singular) and cancelAllRfqs (different entity).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says it cancels all at once with no request body. Implies this is for bulk cancellation, while cancelQuote is for individual. Lacks explicit when-not-to-use but context with siblings provides clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses side effects (inquirer vs. quoter cancellation consequences), rate limit (50 requests/second), and response format (array of results). No annotations are provided, but this description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear sections (purpose, effects, rate limit, hint). Each sentence adds value. Could be slightly more structured, but overall efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description covers all essential aspects: purpose, side effects, rate limit, response shape (array of results), and no request body. No gaps detected.
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?
Since the tool has zero parameters, schema coverage is effectively 100%. The description adds no parameter-specific information, but baseline for 0 params is 4. It does provide context about rate limits and side effects, which are not parameter-related.
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 'Cancel all active RFQs for the authenticated account,' specifying the verb (cancel) and resource (active RFQs). It distinguishes from sibling tools like cancelRfq (singular) and cancelAllOrders by focusing on RFQs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The agent hint clarifies when to use the tool (cancel all active RFQs at once) and that no request body is needed. However, it lacks explicit guidance on when not to use it (e.g., canceling specific RFQs) and does not directly contrast with the sibling cancelRfq.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses parameter precedence, asynchronous response, WebSocket confirmation, and authentication requirement. Exceptionally thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections. Around 150 words, every sentence adds value. Could be slightly more concise but very effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers cancellation behavior, parameter logic, and asynchronous nature. No output schema, but mentions WebSocket for confirmation. Lacks details on error responses or typical success format, but sufficient for a cancellation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description compensates fully by explaining the function and precedence of each parameter (symbol and cancelAll) with concrete examples.
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?
Clearly states 'Cancel all open spread trading orders, optionally filtered by symbol.' Specific verb+resource, and distinguishes from siblings like cancelAllOrders and cancelSpreadOrder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage scenarios including emergency risk management. Explains when to use cancelAll vs symbol. Does not explicitly state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: response is acknowledgement only, cancellation is async, need to monitor WebSocket, and requires authentication. Nothing contradictory.
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?
Well-structured with sections and bullet points. Front-loaded with main action. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides sufficient context for a cancel operation. Explains async response and WebSocket confirmation. Could mention related spread order tools, but not necessary for core functionality.
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?
With 0% schema coverage, the description adds meaning by explaining that orderId is system-assigned and orderLinkId is user-defined. Also clarifies that either must be provided, which is not enforced in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels a single spread trading order using order ID or order link ID. It uses specific verb and resource and distinguishes from sibling tools like cancelAllSpreadOrders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage scenarios (cancel open limit order not fully filled) and identifies required parameters. Mentions asynchronous nature and WebSocket monitoring but does not explicitly exclude other cancel tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers: execution steps (size division, intervals, order types), important notes (minimum 300s duration, price protection, randomization), and rate limit (10 req/s). This fully informs the agent of 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?
Well-structured with markdown headers (When to use, Execution behavior, Important notes, Agent hint), bullet points, and bold emphasis. Every sentence adds value. Front-loaded with purpose. Appropriate length for a complex strategy tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, 0% schema coverage, and no output schema, the description covers purpose, usage, behavior, and important constraints comprehensively. However, it does not describe the return value (e.g., strategy ID), which would help the agent handle the response. Missing explanation for required parameters beyond duration is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It covers TWAP-specific ones (duration, interval, isRandom, chase parameters, triggerPrice) but omits common ones like category, symbol, side, size, reduceOnly, positionIdx, leverageType. These are not defined in schema either, leaving the agent to infer or guess. Explanation of size, side, etc., would have made it complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a TWAP strategy to split large orders into smaller chunks over time, minimizing market impact. It distinguishes itself from sibling tools like createOrder (immediate execution) and other strategy tools (iceberg, DCA) by focusing on time-weighted average price execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use' and 'Do not use' conditions, including examples like 'buy 10 BTC over the next 5 minutes'. The 'Agent hint' section clarifies this is not for immediate execution, directing to regular order creation instead. No other sibling tool description offers such clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses return fields (total value, holdings, PnL, cost basis, price), filtering (non-zero balance only), and usage tips (tradeFlag, tokenCode, chainCode+tokenAddress). Lacks explicit read-only statement but implies it. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, return values, usage tips, exclusions). Front-loaded with main purpose. However, contains redundancy: 'Do NOT' instructions appear both in main text and in the agent hint section, slightly reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, moderate complexity, the description covers all needed aspects: what is returned, filtering, integration with other endpoints (executeRedeem, getAssetDetail), and clear do-not-use scenarios. Complete for the task.
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?
Input schema has zero parameters. Baseline for no parameters is 4. Description does not need to add param info; it correctly focuses on usage guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Query user's on-chain token portfolio' with specific verb and resource. It differentiates from siblings like getAssetDetail (for specific token info) and getBizTokenList (for discovering tokens) by noting that this tool returns only held tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (user asking about assets, balance, holdings, portfolio, PnL) and when not to use (not for discovering new tokens - use getBizTokenList; not for market data on non-held tokens - use getBizTokenPriceList). Clearly states alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return fields, mentions risk flag warning, and implies read-only nature. Could add more detail on behavior (e.g., no side effects), but sufficient.
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?
Concise, well-structured with clear sentences and bullet-like guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a query tool with one optional parameter, the description covers return fields and usage guidelines. Lacks details on pagination or error handling, but overall complete enough.
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?
With 0% schema coverage, description explains tokenTag parameter's purpose (filter by category) and notes it's optional. However, enum values are not described in detail, but context is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: query on-chain tokens available for trading, optionally filtered by tag. It returns specific fields like DEX token code, contract address, risk flag, etc., and distinguishes from siblings like getBizTokenPriceList and getAssetList.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (user wants to discover tokens or expresses buy intent without specifying a token) and when not to use (for prices or holdings), with alternative tool names provided. Also includes an agent hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses: returns hourly data, default behavior (most recent 1 hour), maximum range (30 days), no auth required. It mentions 'Bybit-calculated historical volatility index' but doesn't detail return structure (since no output schema). This is comprehensive but could include more detail on response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, bullet points, and an agent hint. It front-loads main purpose. Although somewhat lengthy, every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (1 required) and no output schema, the description covers behavioral details, constraints, and usage scenarios. Missing detailed explanation for period and quoteCoin, but overall it provides sufficient context for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It adds meaning: category must be 'option', baseCoin defaults to BTC, startTime/endTime must be together or omitted. It mentions period but doesn't explain enum values. The agent hint repeats some info. Overall, it adds significant value but not exhaustive for all 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 tool queries historical implied volatility data for options with hourly granularity. It specifies the resource (historical volatility index for a base coin) and the action (query). It distinguishes from sibling tools like getTickers which provides current implied volatility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this (research historical trends, compare averaging periods, backtesting) and when not to use it (for current IV, use getTickers). It also provides constraints (startTime/endTime must be together or omitted) and potential use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: 2-year data limit, 7-day max span, default period, pagination via cursor, and filter options. No annotations provided, so description carries full burden; lacks mention of rate limits or response format but sufficient for safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured with bullet points and agent hint. Every sentence adds value, no fluff. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no annotations, and no output schema, the description covers purpose, usage, key filters, and sibling distinction. Missing details on some parameters (symbol, coin) and return format, but overall sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning for critical parameters: startTime/endTime (limits), cursor (pagination), orderFilter (type filter), orderStatus (status filter), category (TradFi mapping). Does not cover symbol, baseCoin, etc., but these are inferable from names. Adds significant value over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries historical order records, specifying verb and resource. It differentiates from siblings like getOpenOrders via the agent hint, and provides context like TradFi category mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use (completed/cancelled/expired orders) and when not (active orders, recommending getOpenOrders). Includes max time span, pagination, and filter usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the return (stages with status Done/Active/Upcoming) and is a read-only query. No annotations exist, so the description carries the burden; it adequately discloses behavior but could explicitly state it is read-only and safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load purpose, then example, then agent hint. No fluff; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter query, the description is fairly complete: explains return, gives example, and links to sibling. Lacks details on output format and error handling, but the tool's simplicity mitigates this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one string parameter without description (0% coverage). The description adds meaning by giving a concrete example (eventType=1 for FIFA 2026), helping the agent understand the value space. However, it does not enumerate all valid eventType values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries the tournament stages timeline for a sports prediction event, listing the specific stages returned. It distinguishes from sibling tools like getPredictionGroupStageDetail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: to understand the current tournament phase and navigate to the relevant stage. Includes a concrete example (FIFA 2026, eventType=1) and references the sibling tool getPredictionGroupStageDetail for further steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden and explains the probability interpretation (0-1), the limit of 20 tokenIds, and the data returned. However, it omits potential behavioral details like authentication requirements or rate limits, leaving some room for improvement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with key information. However, it contains some redundancy in explaining the price probability twice, making it slightly less concise than optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains the return values (best bid, best ask, last trade) and the probability meaning. It also includes usage hints and a sibling distinction, making it complete for a simple query tool with one parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It explains that tokenIds specify the tokens to query, imposes a maximum of 20, and implies they are string IDs. It adds value beyond the empty schema but does not detail the format of tokenIds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries current market prices for prediction outcome tokens, specifies the returned fields (best bid, best ask, last trade), and distinguishes itself from getPredictionPriceHistory by explicitly excluding price history queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: call before placing orders, check price before buy/sell, maximum 20 tokenIds per request, and includes a clear directive to not use for price history, referencing the alternative tool getPredictionPriceHistory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description fully owns transparency. It discloses return fields (buy/sell prices, timestamp, quota) and crucially states that prices are for reference only—managing expectations about data quality.
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 with clear structure: one-line summary, bullet returns, important warning, use cases. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with 2 parameters and no output schema, the description covers return structure, caveat, and use cases. Minor omission: no mention of authentication or rate limits, but these are common and likely handled globally.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It implies symbol is the trading pair and paymentMethod filters by payment method, but does not enumerate valid values or formats for paymentMethod. Adequate but not detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Query the reference exchange rate for a specified trading pair' which is a specific verb+resource+scope. It clearly distinguishes from quote-related siblings by noting that actual trading prices come from the quote endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use cases are provided: display approximate rates, compare prices, calculate estimated amounts before requesting a quote. The important note clarifies when not to use (for actual trading).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description covers return values (timeSecond, timeNano), notes on latency during volatility, and states no authentication required. Does not mention rate limits, but for a simple read-only endpoint this is sufficient.
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?
Description is clear and front-loaded with purpose, but slightly verbose with repeated agent hint. Still well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, description fully covers what the tool does, its return values, usage notes, and caveats. Complete for a utility endpoint.
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?
No parameters; schema coverage is 100% trivially. Baseline is 4 per instructions. Description adds no param info but is not needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries Bybit server time and returns seconds and nanoseconds. It distinguishes from siblings by explicitly stating 'Do not use this endpoint for market data' and directing to getTickers or getMarketKline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (clock synchronization, avoid timestamp errors) and when not to use (market data), with alternative tool names. Provides concrete use cases and error codes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It returns estimated receive amount, fees, gas cost, slippage. States agent must display quote to user. Warns not to call without valid token codes. Could mention idempotency or rate limits, but overall strong behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections and bullet points, but slightly verbose. Front-loaded with purpose and returns. Could trim some redundancy in agent hints, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 2 enums, no output schema, and complexity of two trade directions, the description is remarkably complete. It covers usage, prerequisites, token code sources, and agent responsibilities. No gaps for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains tradeType (1=purchase, 2=redeem) and token code orientation for each direction. Does not explain quoteMode or fromTokenAmount in detail, but provides enough context for typical usage. Adds significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a price quote for purchase or redeem trades, specifies the two trade types with token code direction, and distinguishes from siblings like executePurchase, executeRedeem, and getBizTokenPriceList. The verb 'Get' and resource 'TradeQuote' are well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use before executing trades, lists alternatives (getBizTokenPriceList for prices only), and instructs to first call getPayTokenList/getBizTokenList to resolve token codes. Agent hints reinforce correct usage and warn against skipping this step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the response includes acceptable ranges and a check_code, explains what check_code=0 means, and notes no authentication required and rate limit (100 qps per IP). No annotations are present, so the description fully compensates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single well-structured paragraph with front-loaded purpose, usage, response details, and agent hint. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 params, no output schema), the description covers purpose, usage, response behavior, auth, and rate limit. It lacks detailed error scenarios but is largely complete for a validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and while the description lists parameter categories ('investment amount, grid count, price bounds, stop-loss, take-profit, etc.'), it does not explain all 14 parameters individually or add meaning beyond the schema names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Validates the input parameters for creating a spot grid bot' with a specific verb and resource, and distinguishes itself from sibling createGridBot by emphasizing its pre-validation role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this endpoint before calling createGridBot' and includes an agent hint directing to always call it before creation, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavior: max orders, required fields, order status conditions, per-order status field, acknowledgment-only response, and confirmation via WebSocket.
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?
Purpose is front-loaded, followed by bullet points and agent hints. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers limits, preconditions, per-order status, response type, and confirmation method. No output schema, but description adequately explains how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. Explains category usage and required fields per order, but does not detail request array structure or parameter constraints beyond that.
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?
Clearly states the tool cancels multiple orders in one call, with specific verb 'Cancel' and resource 'orders'. Differentiates from sibling cancelAllOrders via hint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (cancel multiple specific orders) and alternatives (cancelAllOrders for all orders). Includes limits per category and a TradFi hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool claims interest, credits to the default account, and that positionId is not required. However, it does not mention idempotency or behavior when no interest is available, but overall it is sufficiently transparent for a simple claim 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 extremely concise, with three bullet points and a rate limit note. Every sentence adds value, and the most critical information is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter, the description covers all essential aspects: behavior, parameter usage, constraints, and rate limit. No output schema is provided, but that is not needed for a straightforward claim action.
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 one required parameter (productId) with 0% description coverage. The description adds meaning by explaining that productId='-1' claims all products, and that productId specifies the product. This provides essential context beyond the schema's basic type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Claim all available interest for the specified product in one click.' It includes a special case for claiming all products at once, distinguishing it from related tools like 'reinvestLiquidity' or 'addLiquidity'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context on when to use the tool, including how to claim all products (productId=-1), that yield goes to the default account, and that positionId is unnecessary. It also specifies the rate limit, aiding the agent in selecting appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: step-by-step execution (1-6), price calculation formulas, frequent order cancellations, API rate limit warnings, and stop conditions. Leaves no ambiguity about the strategy's dynamic behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (When to use, Execution behavior, Price calculation, Important notes, Agent hint). Front-loaded purpose. Every section adds value without redundancy, maintaining clarity despite length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high parameter count (12), zero schema coverage, no output schema, and strategy complexity, the description covers behavior, calculations, constraints, and risk warnings comprehensively. Includes practical recommendations (e.g., percentage ranges, rate limit awareness).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning for key parameters (chaseDistance, chasePercentE4, maxChasePrice) but does not explain category, symbol, side, size, strategyType, triggerPrice, reduceOnly, positionIdx, leverageType. Coverage is partial but crucial parameters are well-explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Chase Order strategy that monitors market price and adjusts order price to improve fill probability. It distinguishes from sibling tools like createTwapStrategy and createIcebergStrategy by providing specific usage scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use conditions (fast execution in volatile markets) and when-not-to-use alternatives (use TWAP or Iceberg for slow execution or hiding order intent). Includes specific 'Agent hint' for quick decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Provides detailed step-by-step execution behavior, including child order calculation, sequential filling, and behavior on partial fills. Covers effect of parameters like postOnly, chaseDistance, and maxChasePrice. No annotations provided, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (When to use, Execution behavior, Important notes, Agent hint). Slightly lengthy but every section adds value. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, high complexity, no output schema or annotations, the description is comprehensive. Covers usage, behavior, parameter advice, and trade-offs. Minor lack of return value specification but overall 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?
Adds significant meaning beyond the input schema: explains relationship between subSize and orderCount, recommends subSize range, clarifies use of chaseDistance='-1' for aggressive taker, and importance of maxChasePrice for price protection. Does not cover every parameter (e.g., reduceOnly, positionIdx), but provides value for key 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?
Clearly states it creates an Iceberg strategy that splits a large order into smaller child orders. Distinct from sibling tools like createChaseOrderStrategy and createTwapStrategy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use (hide large order, prevent price manipulation, reduce market impact, earn maker rebates) and provides a clear agent hint with when not to use (time-sensitive execution) and alternative (Chase Order).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It details that the order is FOK, async ACK response, and that getPredictionOrderList must be checked for fill status. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a summary line, bullet-like prerequisites, and additional details. Every sentence adds value. The 'Agent hint' section slightly repeats but is acceptable for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description covers the ACK response and how to get actual fill status via getPredictionOrderList. All necessary context for a buy execution tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains slippage (e.g., '0.05' = 5%), orderType is only '1' (FOK), and implies tokenId/eventId/amount usage. payTokenCode is not explained but context suggests USDC. Good value despite missing per-parameter breakdown.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute a buy order'), the resource ('prediction outcome tokens'), and the flow ('Pays USDC and receives outcome token shares'). It distinguishes from siblings like executePredictionSell.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit prerequisites are listed (steps 1-4), and the description states 'Do NOT call this endpoint without explicit user confirmation.' It explains when to use (after pre-calls) and covers order type (FOK only) and slippage. Missing explicit alternatives but still very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully carries behavioral info. It declares rate limit '10 req/s' and implies idempotent read operation. Adds field value meanings (e.g., unifiedMarginStatus values) beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, rate limit, agent hint. No wasted words, front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (no params, no output schema), but description covers purpose, rate limit, and field interpretations adequately. No gaps given tool complexity.
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?
No parameters in schema; description states 'No parameters required' which adds clarity beyond the empty schema. Schema coverage is 100% trivially, but description provides explicit instruction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Retrieve unified account configuration including margin mode, account status, and feature settings.' It uses a specific verb and resource, and distinguishes from sibling tools by noting no parameters are required.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit agent hint: 'Use this to check account configuration before performing operations that depend on margin mode or account type.' Also gives field interpretation details. Missing explicit alternatives or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses rate limits, category-specific differences, and return contents. However, it does not explicitly state that the tool is read-only (implied), nor does it mention authentication requirements or error handling scenarios. Slight room for improvement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with about five sentences that front-load the main purpose and progressively add details. There is no redundancy; every sentence adds value (purpose, supported types, return fields, rate limit, usage hints, category differences).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description covers key aspects: what it returns, parameter roles, category-specific behavior, and a usage hint. It could be slightly more complete by explicitly stating output structure differences (e.g., arrays vs objects), but the given details are sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds substantial meaning: explains that category is required, symbol filters for linear/inverse, and that limit/cursor (pagination) are not supported for spot. This compensates fully for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: querying tradable instrument specifications for the user's account. It explicitly lists supported contract types (spot, linear, inverse) and return fields (contract details, leverage, price, lot size filters). This distinguishes it from sibling tools like 'getInstrumentsInfo' or 'getTickers'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use before placing orders, required parameter (category), filtering by symbol for linear/inverse, and important behavioral notes (response structure differs by category, spot lacks pagination). The rate limit (10 req/s) and agent hint further aid correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tool as a batch query that returns market data with no indication of destructive behavior or side effects. It transparently states the input format and output fields, which is appropriate for a read-only data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains some redundancy: the 'Do NOT' instructions appear twice (once in a block, once in the agent hint). It could be more concise by removing duplication while keeping the key guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description enumerates the returned fields (price, 24h change, volume, market cap, liquidity, holder count). It explains the input format, provides source recommendations, and gives negative usage guidelines. This is complete for a market data query tool.
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 single parameter 'tokenAddressInfo' is an array of objects with chainCode and tokenAddress. Schema description coverage is 0%, but the description advises to get these values from getBizTokenList or getAssetList, adding context beyond the schema. However, it does not elaborate on the structure of the array or individual fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it batch queries token prices and market data by chain code + token address pairs. It lists the specific data returned (price, 24h change, volume, market cap, liquidity, holder count) and distinguishes from siblings by explicitly stating what it should not be used for (token discovery vs. getBizTokenList, project info vs. getBizTokenDetails).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use (for token prices and market data given chainCode+tokenAddress pairs) and when not to use (not for discovery or project info). It provides clear alternatives (getBizTokenList for discovery, getBizTokenDetails for project info) and includes an agent hint summarizing usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description is the only source of behavioral info. It states no authentication required and hints at supported indices. While it could mention rate limits or pagination, it adequately covers the read-only nature and scope for a straightforward tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with bullet points, sections, and a clear agent hint. Every sentence adds value without redundancy, making it concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description adequately explains return fields (indexName, lastPrice, updateTime, components array). It covers basic usage and examples, though it could mention error scenarios or edge cases for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by explaining the sole parameter indexName with examples (BTCUSDT, ETHUSDT, XAUUSDT, etc.) and constraints (not available for xStock tokens), adding significant semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves component exchanges and trading pairs making up a Bybit index price, including weights, current prices, and multipliers. It distinguishes from the sibling tool getTickers by specifying that this tool provides composition details, not just the index price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenarios (understand contributions, investigate price differences, research composition) and a clear when-not-to-use (for index price alone, use getTickers). Includes examples like BTCUSDT, ETHUSDT, and TradFi commodities, with notes on unsupported tokens.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It states no authentication required, response schema differs per category, supports cursor-based pagination, and clarifies it is a read-only operation for specifications. This is comprehensive for a non-destructive query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and bold headings, making key information scannable. It is front-loaded with the primary purpose. However, it repeats 'Response schema differs per category' and could trim some redundancy. Overall, it is efficient but slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema), the description provides substantial context: use cases, parameter hints, pagination, and alternatives. It does not fully describe the output structure, but mentions key fields like tickSize, minOrderQty, which partially compensates. It is adequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the category parameter and its enum values by linking to market types. It clarifies the cursor parameter for pagination, the symbolType for TradFi tokens, and implies use of symbol, status, etc. However, it does not directly describe every parameter (e.g., baseCoin, limit), though their use is implied contextually.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool queries instrument specifications for active trading pairs across multiple market types, listing specific use cases like retrieving tickSize, minOrderQty, etc. It distinguishes itself from sibling tools such as getTickers by stating it is not for real-time prices. The verb 'Query instrument specifications' is specific and resource-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use scenarios (e.g., discover available pairs, validate orders) and when-not-to-use (not for real-time prices, suggesting getTickers instead). It includes an agent hint for TradFi discovery with symbol type guidance and pagination usage. This clearly guides the agent on appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. It clearly indicates this is a query (read-only) operation by using 'Query' and describing checking before actions. It transparently states the consequence of unavailability (orders cannot be submitted). While it doesn't explicitly state 'no side effects,' the verb and context strongly imply idempotence and safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (four sentences) and front-loaded, with the core purpose in the first sentence. Every sentence adds value: purpose, consequence, agent instruction, and a hint. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description covers all necessary context: what the tool does, why it matters (blocking orders), and how to act on the result (inform user, do not proceed). It implies the response includes an 'available' boolean, sufficient for an agent to interpret. Fully complete for this simple status tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the baseline is 4. The description adds no parameter details (unnecessary). It appropriately focuses on the tool's purpose and usage. No further parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Query whether the prediction market matching engine is currently available,' using a specific verb ('Query') and resource ('engine availability'). It clearly distinguishes this tool from sibling trading and market data tools by focusing solely on engine status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'AI agent should check engine status before attempting to place orders' and 'If the engine is unavailable, inform the user and do not proceed with trading.' It also includes a direct agent hint to call this before placing any buy/sell order, clearly defining when to use it and what to do based on the result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses latency during high volatility and no authentication required. It also notes the return format (list with one ticker object). Minor omission: no mention of rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points, sections, and front-loaded purpose. Each sentence adds value, no redundant or unclear phrasing. Appropriate length (around 150 words).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage guidelines, parameter details, latency, authentication, return format, and alternatives. Complete for a simple read tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides no description for the 'symbol' parameter (0% coverage). The description adds meaning by stating it's required and advising to use getSpreadInstrumentsInfo to obtain valid symbols, compensating well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves latest price snapshot, best bid/ask, and 24h stats for a spread symbol. It distinguishes from sibling tools like getSpreadOrderbook (depth) and getSpreadRecentTrades (trades).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (current price, 24h stats, best bid/ask) and when not to use (order book depth, recent trades) along with alternative tool names. Also provides agent hint and guidance on obtaining valid symbols.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: it notes secrets are never returned, IP whitelist format, permissions parsing, account status fields, and a 5-minute cache for KYC. It is read-only and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections and front-loaded purpose. However, it is verbose, especially with process flow and parsing details that may be extraneous for an AI agent's decision-making.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and zero parameters, the description is comprehensive: it lists 10 categories of returned info, explains key behaviors, and covers use cases. It leaves no gaps for an AI agent to understand what the tool does and returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description adds crucial context that the tool operates on the authenticated API key automatically. This goes beyond the empty schema to clarify how the key is determined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries 'comprehensive information about an API key' with a specific verb and resource. It distinguishes from siblings like listSubAPIKeysV5 by focusing on the current API key used for authentication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use the tool with a master or sub-account's API key, and it can only query the key used for authentication. It does not explicitly mention when not to use it or provide alternatives, but the purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 discloses the rate limit (5 req/s), eligibility rules, and empty response scenario, which are important for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only a few sentences with bullet points for rules. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could briefly mention the response format or structure. However, it covers the core purpose and rules adequately for a simple query with no parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the description appropriately describes the purpose without needing parameter details. The description adds meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get your exchange broker account entity total rate limit usage and cap', which uses a specific verb and resource, and distinguishes from sibling tools like queryBrokerAccountInfo and queryBrokerAllUidDetails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit rules: only Main UIDs can query, only exchange broker accounts can call, and empty response if not applied. However, it does not explicitly mention when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it returns type 6 custodial sub-accounts, pagination details (cursor-based, default page size 100, nextCursor=0 indicates last page), permissions required, and response fields. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and bullet points, front-loading the purpose. It is slightly lengthy but each sentence adds value, making it clear yet organized. Some redundancy exists (e.g., 'Important notes' followed by list) but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (sub-accounts, pagination, permissions) and no output schema, the description provides enough detail: response fields (UID, type, status, mode, etc.), pagination behavior, and required permissions. An agent can correctly invoke and interpret the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), but the description adds meaning by explaining pagination: cursor-based navigation, default page size 100, maximum 100, and interpretation of nextCursor. This goes beyond the schema's raw definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries escrow sub-accounts in paginated format, with specific verb 'query' and resource 'escrow sub-accounts'. It distinguishes from siblings by focusing on fund management type sub-accounts, avoiding confusion with other account-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use: Private Wealth Management scenarios, trading teams managing client funds, and requiring a trading team API key. It specifies what it returns (only escrow sub-accounts bound to the requesting team) but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It details the process flow (UID extraction, validation, default page size, cursor parsing), pagination mechanism (cursor-based, nextCursor logic), status values, and business rules (e.g., 'Only returns Friend referral invitations'). It also explains error conditions (permission denied for invalid UID) and sorting order (newest first).
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 quite long with multiple sections (process flow, pagination, business rules), but it is well-structured and front-loaded with the main purpose. It could be more concise, but the organization aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no required parameters and no output schema, the description covers all necessary details: return fields (invitee_uid, status, timestamps), pagination mechanism for fetching multiple pages, business rules, authentication requirements, and error handling. It is comprehensive for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters with 0% schema description coverage, so the description must add meaning. It thoroughly explains: 'cursor' parameter behavior (initial request omit, subsequent use nextCursor), 'size' defaults and range (1-100, auto-adjusted to 20 if invalid), and 'status' values (0=active, 1=inactive, returns all if omitted). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Query invited users (referrals) for the authenticated account.' It specifies the resource (referrals) and action (query). It distinguishes itself by noting 'Only returns Friend referral (scene=2) invitation records', which differentiates it from other user-related tools like getAffiliateUserList.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: 'Use master or sub-account's API key' and 'Must be authenticated with valid API key'. It lists use cases (e.g., 'Query all users invited by the authenticated account'). However, it does not explicitly mention when to avoid using this tool or compare it to similar tools like getAffiliateUserInfo.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it fully delivers. It explicitly states that the upgrade is IRREVERSIBLE, requires user confirmation, and must never be triggered automatically or based on AI-readable instructions. This goes well beyond the schema and gives an agent the safety-critical context needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with the main action first, followed by concise bullet-point prerequisites and a highly relevant agent hint. Every sentence earns its place, and the critical irreversible/confirmation warning is prominently highlighted. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, irreversible mutation tool with no output schema, the description is complete. It covers eligibility, preconditions, timing, irreversibility, and confirmation requirements. Nothing an agent needs to safely and correctly invoke this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter, confirm, already has a clear description in the schema requiring it to be true only after explicit confirmation. The tool description reinforces this in the agent hint but does not add meaningful new param-level semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Upgrade eligible UTA2.0 account to UTA2.0 Pro status.' It clearly distinguishes this irreversible account upgrade from the many sibling trading, subscription, and query tools, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit eligibility conditions and precautions: unifiedMarginStatus=5, VIP/PRO master account users, no open orders, and a time window to avoid. The agent hint further states when the tool may be called—only after explicit user confirmation—and forbids automatic triggering. This is strong, actionable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that response is acknowledgment only, advises using getLPPositionList for confirmation, and mentions 10-60 second on-chain delay. Also warns about prerequisites and user confirmation requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose, prerequisites, warnings, and hints. Front-loaded with key info. Some repetition of 'user approval' but each section adds value. Could be slightly more concise, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and complexity, description is comprehensive. Explains workflow: verify balance, get pool info, display details, confirm, execute, then poll getLPPositionList. Mentions on-chain delay. Relates to sibling tools appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds key parameter insights: positionId semantics, poolAddress, payTokenAmount, payTokenCode, and constraint to use either range or price pairs. Lacks full parameter descriptions but compensates with usage rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute LP stake to provide liquidity and earn rewards.' It returns a position ID for tracking. This distinguishes it from sibling tools like executeLPRedeem (redeem) and getLPPositionList (read).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisites: call getLPPayTokenList and getLPPoolInfo first, display details to user, obtain explicit confirmation. States 'Do NOT call this endpoint directly without user approval.' and gives parameter usage rules (positionId=0 new, non-zero adds; use range/price pairs, not both).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: data updates every 1 minute, no authentication required, optional symbol parameter retrieves all data, and explains key metrics (pnlRatio, insurancePnlRatio). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections and bullet points, but slightly verbose with repeated agent hint and data update frequency mentioned twice. Could be trimmed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and one optional parameter, the description covers all necessary context: purpose, usage guidelines, data freshness, parameter behavior, and alternative tools. No 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?
Only one parameter (symbol) with 0% schema description coverage. The description adds meaning by explaining omitting symbol retrieves all symbols, which is critical for usage. Baseline for 0 parameter descriptions is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries ADL alert data and insurance fund metrics for derivative contracts, listing supported products and distinguishing itself from getInsurancePool. The verb 'Query' and target resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases (monitor ADL risk, check insurance fund balance, understand thresholds) and an explicit when-not-to-use ('Do not use for general insurance pool balances — use getInsurancePool instead'). The agent hint reinforces this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the read nature ('Returns'), rate limit (20 req/s per UID per path), and implies safety. It does not mention authentication or caching, but the provided details are sufficient for a get tool. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly written: one sentence for purpose, one for rate limit, one agent hint with usage instruction and alternatives. No redundancy, easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers all needed context: what it returns, prerequisite (aurora_id), suggested workflow, and rate limits. Complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, aurora_id, is described as 'encoded ... previously returned by one of the recommendation endpoints', adding crucial context beyond the schema's bare type definition. This clarifies source and format, fully compensating for 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Returns the full Aurora AI strategy (params + backtest metrics)' identified by an aurora_id. It distinguishes from siblings by explicitly directing users without an aurora_id to recommendation endpoints, making its purpose specific and non-overlapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use when you have an aurora_id to refetch/refresh; do not use if you lack an aurora_id, in which case call one of four named recommendation endpoints first. This fully covers when-to-use, when-not-to-use, and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals key traits: 'No authentication required', 'Isolated pool updates every minute', 'Shared pool updates daily', and 'The insurance fund absorbs losses from liquidations to prevent auto-deleveraging (ADL).' This provides essential behavioral context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and clear sections. It front-loads the main purpose. However, it is slightly verbose, including explanatory background on insurance funds and agent hints that could be more concise. It earns its sentences but could trim some redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately indicates return values: 'balances and USD-denominated values'. It covers the single parameter and provides usage context. However, it lacks specifics about the exact structure of the response (e.g., fields like 'balance', 'value'). For a simple query tool, this is nearly complete but could benefit from a brief note on response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the single parameter 'coin'. The description compensates by explaining the parameter's effect: 'Returns all insurance coins if coin is omitted.' and provides usage examples ('e.g., USDT, BTC'). This adds significant semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Query Bybit's insurance pool balances and USD-denominated values for various settlement coins.' It specifies what it does (query insurance pool) and the resource (settlement coins). It distinguishes itself from siblings like getAdlAlert by focusing on insurance pool health, not ADL thresholds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'Use this endpoint when you need to: - Monitor insurance fund health... - Understand which contracts share a pool... - Check current pool balance...' It also clearly states when not to use it: 'Do not use this endpoint for ADL threshold details — use getAdlAlert instead.' This offers clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavioral traits: data returned in reverse chronological order, up to 1000 records per request, no authentication required, and the 7-element array format. Provides comprehensive transparency beyond what annotations would typically convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections and bullet points, but slightly redundant (reverse chronological mentioned twice). Still concise for the information provided, with front-loaded key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description covers purpose, usage, data format, limitations, and alternatives thoroughly. It provides enough context for an agent to invoke the tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds context: start/end timestamps in milliseconds, supported categories (spot, linear, inverse), and limit max 1000. While not detailing every parameter, it compensates with useful semantics that the schema lacks, though slightly verbose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it queries historical klines (OHLCV candlestick data) and lists the fields. It distinguishes from sibling tools by stating 'Do not use this endpoint for mark price candles — use getMarkPriceKline instead' and similarly for index price, clarifying its specific resource and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenarios: building price charts, technical analysis, data for time range. Also gives clear when-not-to-use with named alternative tools (getMarkPriceKline, getIndexPriceKline, getPremiumIndexPriceKline), offering strong guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behaviors: historical data only, cursor-based pagination, potential latency during volatility, no authentication required. These details go beyond the minimal and inform the agent of operational characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with introductory paragraph, bullet points for use cases, clear notes, and an agent hint. Every sentence adds value, no redundancy, and it's front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: purpose, parameters, pagination, latency, products, and alternative tool. Lacks explicit response structure description, but given no output schema, the description still provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by naming required parameters (category, symbol, intervalTime) and explaining interval values, cursor pagination. Leaves startTime, endTime, limit somewhat ambiguous but provides essential guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries historical open interest data and returns total outstanding position size. It distinguishes itself by specifying 'historical' and contrasting with getTickers for real-time data, which avoids confusion with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists use cases (track changes, analyze trends) and provides a clear 'Do not use' directive with alternative tool (getTickers). Also lists supported intervals and products, offering comprehensive when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that Phase 1 supports only FOK orders, that unfilled FOK orders are cancelled entirely, and lists returned fields (estimatedCost, estimatedReceive, feeAmount, toWin).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and bold emphasis. Front-loaded with purpose. Could be slightly more concise, but every sentence adds value and the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a prediction market estimation tool, the description covers required parameters, behavioral constraints (FOK-only), and what to show the user. Despite no output schema, it mentions key return fields. Complete for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description adds detailed semantics for side, amount, payTokenCode, and orderType. It explains side=1 is BUY (amount in USDC) and side=2 is SELL (amount in shares). eventId and tokenId are not explicitly described but context implies their purpose.
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?
Clearly states it estimates execution details for a prediction market order before placing. Distinguishes itself by emphasizing it's mandatory before any buy or sell, and provides explicit BUY/SELL parameter guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Mandatory before any buy or sell' and instructs the agent to show estimated results to the user. Provides clear parameter mapping for BUY vs SELL, and mentions supported order type (FOK only).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: async acceptance (order not settled on success), rate limits, idempotency constraints (orderLinkId persists per category), quote validation (stale quotes rejected), slippage protection (SmartLeverage initialPrice ±5%), redemption restrictions (60 min for SmartLeverage, 30 min for DoubleWin), and error handling (error 180030). Comprehensive.
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 long but logically structured: core purpose, prerequisites, rate limit, general notes, then per-category sections with bullet points. Every sentence is informative and necessary given the complexity. Minor trim could improve conciseness, but the structure is excellent for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (14 params, nested objects, 4 categories, no output schema, no annotations), the description is highly complete. It covers prerequisites, async behavior, error conditions, redemption rules, and field sources. The only minor gap is lack of explicit description of the response payload (e.g., order ID), but it directs to Get Order for tracking, implicitly covering return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden. It explains every nested object's fields: e.g., smartLeverageStakeExtra.initialPrice is current market price, breakevenPrice must come from Get Product Extra Info; doubleWinStakeExtra.leverage not exceeding product info, lowerPrice/upperPrice required for RFQ; discountBuyExtra fields explained in detail with precision constraints. The description adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: 'Place a Dual Assets staking order.' While the title is missing, the verb 'Place' and the specific resource 'AdvanceEarnOrder' are clear. The description expands to cover multiple categories (DualAssets, SmartLeverage, DoubleWin, DiscountBuy), and the tool name distinguishes it from siblings like placeEarnOrder, placeFixedTermOrder, and placeTokenOrder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidelines: requires 'Earn' permission, 5 req/s rate limit, asynchronous processing, quote freshness (selectPrice/apyE8 must match valid quotes), idempotency via orderLinkId, and detailed per-category instructions. It also references when to use ancillary tools (e.g., Get Order for tracking, Get Product Extra Info for quotes, Get Redeem Estimation). No contradictions or misleading guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral constraints: price range rules (lowerPrice < initialPrice < upperPrice, multiples of priceTickSize), and that returned leverage and expireTime are used for placing a Stake order with an expiration. Rate limit is also specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a brief main sentence followed by bullet points for conditions, prerequisites, rate limit, and notes. Every sentence is valuable, no redundancy. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 required parameters, no output schema, and no annotations, the description covers prerequisites, constraints, usage instructions, and follow-up actions (placing Stake order). It also references alternative tools for other cases, providing complete context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning: it explains the relationship among lowerPrice, initialPrice, upperPrice, and mentions productId and initialPrice implicitly. It also describes constraints and their purpose. However, it could provide more detail on productId and initialPrice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Query the leverage for a Double Win RFQ product with user-selected price range.' It distinguishes from fixed-range products by specifying 'Only applicable for RFQ products' and directing to alternative sources for fixed-range products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Only applicable for RFQ products (isRfqProduct=true).' Provides alternatives: 'For fixed-range products, obtain leverage from Get Product Extra Info or the WebSocket topic.' Also includes prerequisites ('Requires Earn permission') and rate limit ('1 req/s').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses data delay up to 1 minute, default limit of 50 records, no authentication required, reverse chronological order, and default settleCoin=USDT. No annotations provided, so description carries full burden and meets it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and sections. Front-loaded with main purpose. Slightly redundant (agent hint repeats info) but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive given 3 parameters, no output schema, and many siblings. Covers use cases, constraints, timing, defaults, and alternatives. Includes agent hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description adds meaning: category must be 'option', baseCoin required, settleCoin defaults to USDT. This compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves historical option delivery prices grouped by base coin and settlement coin in reverse chronological order. It explicitly distinguishes from sibling getDeliveryPrice by specifying it's for options and not futures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (look up recent option settlement prices by base coin, retrieve latest delivery price after settlement) and when-not-to-use (futures delivery prices -> use getDeliveryPrice, specific contract symbol -> use getDeliveryPrice). Also advises waiting 1 minute after settlement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 honestly describes the tool as a query returning aggregated summary data with no side effects. It also includes an agent hint about usage, fully disclosing the tool's behavior and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded. Every sentence adds value: first sentence states purpose and returns, second gives use case, third gives agent hint with alternatives. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, but sibling tools exist, the description is complete. It lists all returned fields and provides clear context for when to use this tool versus siblings. No 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?
Input schema has 0 parameters, so schema coverage is 100%. According to guidelines, baseline is 4. The description does not need to add parameter info as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries an aggregated summary of the authenticated user's prediction market portfolio, listing specific return fields. It distinguishes itself from sibling tools getPredictionPositionList and getPredictionPositionHistory by explicitly stating when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use for high-level overview, and for individual position details use getPredictionPositionList, for historical P&L breakdown use getPredictionPositionHistory. This clearly indicates when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description comprehensively discloses behavior: cursor-based pagination, sorted by createdAt descending, parameter interaction rules, time restriction on rfqLinkId, and rate limit. No destructive behavior implied.
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?
Well-structured with clear sections: main purpose, pagination/sorting, real-time caveat, parameter rules, rate limit, agent hint. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description covers essential usage aspects: filtering, pagination, sorting, parameter constraints, rate limit, and alternative tools. It is self-contained enough for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It explains optional filtering by ID, trader type, and status, and clarifies parameter interactions (rfqId vs rfqLinkId, rfqLinkId time restriction). However, it does not explicitly mention the limit range or cursor usage details, though pagination is noted.
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?
Clearly states 'Query historical RFQs' with optional filtering. Distinguishes from sibling tool getRfqsRealtime by explicitly noting this is for historical data, not real-time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'This data is not real-time. Use the Get RFQs (real-time) endpoint for live data.' Also explains pagination and constraints on rfqLinkId, helping the agent choose the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully explains behavior: returns up to 25 levels per side, bid/ask sorting, u field for correlation, no auth required. It also explains default limit behavior and return fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with intro, bullet points, notes, and agent hint. However, some repetition exists between usage points and agent hint. Still concise overall with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema, the description explains return fields (bid/ask levels, sequence, timestamp) and ordering. It also covers correlation with WebSocket and default limit. Sufficient for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description compensates fully. It explains symbol must be valid spread combination (with reference to getSpreadInstrumentsInfo) and limit default=1 for best bid/ask, with range up to 25.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves spread orderbook depth data for a specific spread symbol, with specific verb 'Retrieve'. It distinguishes from siblings like getSpreadTickers by explicitly stating what not to use it for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage scenarios are listed ('when you need to... inspect current bid/ask depth, fetch best bid/ask, correlate with WebSocket'). Also includes explicit 'Do not use' with alternative tool (getSpreadTickers). Agent hint provides additional guidance on symbol and limit.
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:

[![trading-mcp MCP server](https://glama.ai/mcp/servers/bybit-exchange/trading-mcp/badges/card.svg)](https://glama.ai/mcp/servers/bybit-exchange/trading-mcp)

Score Badge

Copy to your README.md:

[![trading-mcp MCP server](https://glama.ai/mcp/servers/bybit-exchange/trading-mcp/badges/score.svg)](https://glama.ai/mcp/servers/bybit-exchange/trading-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bybit-exchange/trading-mcp'

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